If you fail to plan, you plan to fail.
Most projects will start development too early and can easily waste the first $100k of their development budget if not more by not being deliberate about what is getting built and how. To help business leaders prevent this, we've created the Get It Built Definition Phase. We're inspired by our time at the Stanford d.school, the YCombinator curriculum, product development practices at big and small tech companies, and our own real-world experience developing dozens of early-stage products.
In this part of the process, the product manager and the business leader work together to:
Define the problem and solution space
Identify a creative direction
Break down assumptions and misconceptions
At this stage, we commit to what we're building in the broadest possible sense. We test our hypotheses about who our users will be, what their problems are, what goals we want to help them achieve, and whether or not that can be a viable business. We also get creative and expand our definition of what our solution could be and what it could be like.
Defining your user personas will help you think of your users throughout the definition and development process in a certain way. Knowing who your users are and aren't will help in making decisions, prioritizing features, and communicating the value of your solution.
User stories give a clear purpose to your user journey through the solution. This step is where we list everything we want our different user personas to be able to achieve through the use of our solution. The focus is here is outcomes rather than mechanics, and desirability rather than perceived feasibility. In other words, this is closer to a wishlist than a feature list.
The mood-boarding exercise consists of bringing together all your sources of inspiration. A mood board includes things like screenshots, images, features, colors, personalities, brands, words, ideas, quotes, or even scents and sounds. At this stage, the goal is not to make sure things match but rather collect everything we like.
Usually, when people have an app idea, they can visualize it in their minds. Sometimes we get unreasonably attached to the first version of our idea, so a step that should not be foregone is brainstorming. Informed by your users and your own experience, it is important to bring different perspectives together, remove boundaries, and explore the possibilities for solutions to your users' problems. We recommend Ideo's flavor of brainstorming as it is the inspiration for ours.
In this part of the process, the product manager and app architect work together to balance the following priorities:
Creating a great user experience
Making the best use of resources
In more concrete terms, we are deciding what the highest quality experience we can give users is (given our timeline and budget constraints) while setting up for technical success. We combine the user experience focus of the product manager, the technical focus of the app architect, to create a definition of what goes into the build.
Confident that we have explored all our options, we switch gears to making decisions. Feature lists at Get It Built are created with the MVP (Minimum Viable Product) mentality.
We focus on creating value for your users as quickly as possible. It is not useful to compare yourself to products built by companies who have raised 1000x more than you to expand their product. Speeding up development for us is by reducing the quantity, not the quality of features. Bigger companies have the bandwidth to do more, but they also set the ever-increasing standard for design that we should meet with our MVP. If we focus on the essentials, we can use your MVP to give value to users, and then expand on it to scale when we have validation. At this point, you should be giving users enough value that they are looking forward to the rest of the app rather than not using it because you are missing some features. If the latter is happening, you need to rethink, review, retarget, and retest. If you get this right, you will have product-market fit before even finishing your product. Our rules are simple:
Less is more.
Simplicity is key.
A feature list tells you what the product should do, and the wireframes show you how it should do it. The key here is to get ideas on paper. We suggest starting with paper and pencil and then move on to higher fidelity tools. The primary goal here is to concretize your thoughts, sharing them with customers and teammates, exploring new possibilities, and deciding what the product is going to look like at a high level. This process is very iterative. The more questions, concerns, and possibilities are brought up and resolved at this stage, the more clarity we will have later. At this stage, changes are incredibly easy and have no hidden costs, but each time we wait on solving an issue, the costlier it gets to do so. Feedback and iteration on wireframes should happen on the topics of functionality, layout, and flow without the distraction of fonts and colors. The look is the next step.
Taking the requirements from the previous step, the product manager and the designer create a visual representation of the product. The most important considerations in this step are:
The result of this step is a visual representation of the user-facing parts of the app. Iteration is key in this step as we have the most flexibility to make changes and clarify the requirements and user experience. A few key products at this stage are the wireframes, style guides, mockups, and clickable prototypes. Each has different levels of fidelity, and all work as building blocks and alignment tools.
When the core of the app is defined, we can focus on finding the style for your app that your users will love. The style guide will resemble your branding guide. It includes colors, fonts, logos, icons, images, and other assets and design specifications to be used throughout the product.
The next step is combining how things should look with how things should work to define the details of the user experience. The beauty of mockups is that they leave nothing to the imagination. The goal here is a pixel-perfect nonfunctional rendering of your product.
With all the functionality clarified with the user in mind, the product manager and app architect reconvene to get specific on the engineering tasks that have to achieve our common goals. A few considerations:
Engineering roles and respective experience levels needed
Costs of development vs. integration
Appropriate tools and technologies for the given task
A complete app architecture is one that allows engineers to understand what is expected of them to turn an idea from concept to reality.
In this step, our team will define the frontend, backend, and database technologies to use to meet the unique needs of your product best. We also determine the third-party integrations, development and deployment tools, and quality assurance technologies we will need to use.
What technologies do you need to use? AWS or Google Cloud Services, iOS or Android, Mobile Web or Native, React or Angular, Node or Django, Relational Databases, or NoSQL?What outside services do you need to use? Think payments, authentication, social, location services, notifications, and so on.
The architecture diagram represents the relationship between the services we are building. This diagram includes interfaces, integrations, servers, services, and databases. We will define each component by its function in the system and the technologies used to implement them.
How many databases, services, and interfaces do we need? What is the relationship between them? How should we communicate between the services? How can this be optimized to protect the system from threats?
An Entity Relationship Diagram (ERD) defines the structure of your data. It's important to know, not just the fact that you need to store a type of data in your database, but how that data should be stored.
What data objects do you need to store? What fields should be associated with those objects? What is their relationship? How will it be retrieved most frequently, and how can we optimize storage for retrieval?
In this step, we use a combination of plain English and pseudocode to define and describe the algorithms and business logic we will need to implement to enable the product functionality we desire alongside the potential challenges of a particular implementation and performance requirements.
What algorithms do you need? A typical example is a feed. You need to decide in which order the items are going to show up and what factors are going to affect the order. Does everyone see the same feed? Does the time of day affect the feed? Can the user filter the feed? How? Another example is interpreting user data to give them an answer to a question they may have. If you input all of your transactions, for example, the algorithm for showing the total spending for a month would have to be designed and built. Even a simple proposition like this one has many considerations. How do you define a month? 30 days? Days since the first? Days in the past month?
The goal of the Definition Phase is to ideate and iterate in the lowest-cost way possible, before a single line of code is written. After building dozens of products, we have organized this process into single focus steps to ideate, define, design, and engineer your product. We hope this post communicates the importance of investing in a definition phase that shares with developers your business, visual, and technical requirements.
Where are you in the process?
I need help with definition. Get a customized Definition Phase Quote.
I am ready for development. Learn more about our offering and capabilities.