Building products is an ongoing, iterative process. The way we work, think about problems, and create solutions change. Each problem will be approached in slightly different ways, but this is a simple, high level framework for how I approach thinking about and developing any new ideas.
The discovery phase allows us to pave a clear direction for a project. This is the time where we define, discuss and question a problem.
Our goal is to
- Define the problem
- Define who we want to solve the problem for
- Understand bottlenecks that current solutions face
- Articulate why we want to solve this problem
Why do we believe the problem is something worth solving? Is it even a problem at all?
Asking why allows us to better understand the problem itself, allowing us to approach a solution that is formed directly around the problem and limiting poor assumptions.
Every problem is a problem because it affects something or someone. We ask who is affected by our defined problem.
Now's a good time to look at public data, competitive products, create user profiles to categorize different types of customers, and interview current and potential customers. During this phase we might even create a quick prototype of an idea and share it with a selective group for suggestions and feedback.
What is the initial solution that we have for our problem? Are there already solutions out there for this problem? If so, what bottlenecks do these solutions face?
It is good to find a few key distinguishing approaches that we will take apart from competitive products we defined above.
How will we measure our success?
We need a definitive answer for this question — it will prevent us from working endlessly at an unreachable goal. This can be defined by meeting deadlines, quality expectations, expectations of stakeholders, our ability to stay within costs, to the product's performance relative to its overall business purpose.
This is the time we take our assumptions, and begin sketching, prototyping, and building out the idea through code.
a. Information Architecture
Define and structure the different sections/modules of an idea based on our assumption of a user's journey through the application. We ask ourselves what questions the user may have during this time, and create a structured flow of moving through the application based on these questions.
b. Sketch & Wireframe
We begin with low fidelity wireframes and ideas sketched in a notepad. Based on the information architecture we created, we use this time to design the basic layout and structure of where each item will be placed.
c. High Fidelity Prototype
We take note of and iterate our final product based on customer feedback.
Deploy, Distribute, & Iterate
Once our roadmap has been met, we bundle together the final product, and launch.
a. Feedback & Analysis
How are users responding to our product? Based on earlier feedback during our development phase, were the feedback that we implemented taken well? What are some critical items that we need to improve immediately?
b. Retrospective & Learnings
Did we meet our definition of success?
This is the time to reflect on what happened during our entire process. Ask questions like what worked well for us? What didn't work so well? What actions and processes would we do differently the next time?
Product development is an ongoing process — we always need to reflect, iterate, and update our approach in order to become better problem solvers.
We'll take things that worked well and apply them to the next iteration, and improve upon the things that could've been better.