Product Architect | Tech Inventor | Entrepreneur
One of the most important steps in the product development process — is the understanding and proper articulation of the problem. It is a good idea to use a model, a structure to help you formulate the problem with clarity.
Start by describing the ideal situation versus the current one, and how certain users are impacted by this gap
Support your problem statement with statistics and facts — for example figures to describe the size of the problem or the potential of the opportunity. Keep it simple and clear- a structured, well-understood articulation of the problem with no technicalities and fancy terms.
The problem statement should become part of your ‘common corporate language’: your team, your investors, your sponsors and other stakeholders should all be able to instantly understand it and reference it when reviewing your solutions and product plans.
Make sure you know who you are solving for! Identify and name the different classes of users in the context of your problem; document their needs and the problems they are experiencing; identify their pain points; their expectations, and the best-possible experience they could have in this context.
Define Success criteria for each class of users.
Identifying your users is different from understanding your users. You need to apply empathy, study your users and deeply understand their profiles, habits and needs. You could use existing research and public domain insights; or host user interviews and focus groups — to validate both your problem statement and your potential solution.
Having your problem defined with clarity, allows you to validate it with your key stakeholders — including your customers or end-users: challenge the problem and make sure it is worth-solving; study the impacted users and document how they are affected by this problem. During this process, try to answer the following questions:
At this point, you must also scan the market and the state-of-the-art to figure out if there are existing products or services — addressing the same problem; and if so, it is critical to understand how.
Having a well-defined and validated problem, enables you ideate and explore potential solutions. At this stage, I would recommend starting by setting the context — make sure your team is aligned and has a deep, shared understanding of the problem space — the situation, the ideal state, the users, the personas; the pain points and the opportunity.
Then, move on to an ideation phase — you need ideas on how to solve the problem and provide value to your customers. Ideation could take the form of a series of brainstorming sessions, or design sprints or internal contests like hackathons.
Whatever the form or methods you select, make sure your team is capturing all of the ideas, into a system. This is important to allow fast iterations over this set of ideas, and post-processing: you will have to evaluate each idea and attach metadata and artifacts as you go. Depending on the scale of your initiative, an ideation system could add significant value by organizing and speeding up the entire process.
Assuming a set of great ideas and potential solutions is there, iterate through the following steps:
The Minimum in the MVP implies that you already have the Big Picture, the product vision! A common mistake is when the team ‘easily’ identifies a set of ‘obvious’ use cases as the MVP — without a clear product vision and a good definition of the ‘complete product’.
Assuming you have this bold product vision, the next step is to define your ‘complete product’ as a long list of User Stories — your product backlog. It is important to understand here, that this is the full version of your product / not just your MVP!
Another important point is that you don’t have to apply feasibility, cost or other constraints at this stage; my advice is to describe everything — even the most crazy and expensive product features, as you will be able to prioritize and manage them at a later stage.
This way, you don’t have to skip, drop or archive an idea for a feature that looks ‘ahead of its time’ or not well-understood yet. Instead, you should include them in your backlog with a lower priority — but they will still remain discoverable and potentially useful in the right context.
Iterate and keep defining more user stories, until your product is described in full .Your ‘full product’ backlog should have all the features you can think of, reflecting the needs of all users identified so far; and all in the form of solid user stories.
A this point you have the definition of your ‘full product’ — the complete not the minimum. What you need now, is a process to find the best minimum subset of features from the complete product backlog.
This ‘best minimum subset of features’ which delivers enough value to your early customers to keep them happy and engaged, is what the MVP is all about: the first instance of your real product, which will help you to go to market faster, with minimum implementation costs and the right feedback loops enabled.
To find this minimum subset, analyse carefully each User Story — in terms of value to the user, the importance in solving the problem and also in terms of cost and feasibility. This way, all user stories in your product backlog will get a priority (a number — ideally as a function of the expected value and feasibility).
Next step is to rank the User Stories, with the highest priority at the top; then, you have to apply business and product sense to draw the red-line which will define the top-n stories as the basis for your MVP.
By now you have a great basis for building your MVP: you have a solid problem statement, deep understanding of your users, the market and the technology, along with a prioritized product backlog.
Before you start implementing your product, it is a wise move to define specific Success Criteria — and how to track the involved figures. Identify the key metrics and the underlying data points; define and document the KPIs (Key Performance Indicators) — which will reflect the performance of your product against time and other dimensions.
Think of how your assumptions and hypotheses are linked to those metrics and KPIs. Setup a system to monitor these KPIs and how close they are to the pre-defined success. You will probably need a funnel to measure conversion rates and a special dashboard — as a single and reliable point of reference regarding the performance of your product.
The process described so far, will hopefully give you a well-defined MVP. You will know what to build, why, for whom and possibly when and how.
But this is just one part of the story: to succeed you have to ‘make it happen’— you need an excellent MVP execution as well. Follow modern agile engineering practices — build, measure, learn and iterate fast; always with the user in mind.
Comments, suggestions and questions welcome! https://www.linkedin.com/in/gkrasadakis/
Cover image: pixabay
Level up your reading game by joining Hacker Noon now!