Product strategizing refers to the activities required to determine if and why a product should be developed. Carrying out this work makes it more likely to create a product that users want and need. In this article, I share my recommendations to help you improve your product strategy work.
Bring the Right People Together
Product strategy is a team sport. You should therefore involve the right people in the work and secure enough of their time. I find it helpful to form a team that consists of:
- Development team members: user experience (UX) designer, developer, tester;
- Key stakeholders, for example, representatives from marketing, sales, and support;
- A Scrum Master, agile coach, or product coach.
Involving these individuals in the strategizing work allows you to leverage their knowledge and expertise, builds rapport, and creates support for key product decisions including the selection of a specific market segment and stand-out features.
A UX designer, for example, might help you observe and interview users; and a developer and tester might advise you on technical feasibility, identify technical risks, and build prototypes; a sales rep might get you in touch with prospective customers and help you with competitor research; a Scrum Master might facilitate collaboration and advise on process issues—for instance, which process and tools should be best used to visualize and track the discovery work. (I prefer to use a Kanban-based process and a Kanban board to organise product strategy validation work, as I discuss in my book Strategize in more detail.)
Focus on Problem Validation, not Solution Building
Your product strategizing should focus on nailing the value proposition, target group, business goals, business model, and stand-out features of the product—not determining individual product features, writing user stories, designing the user interface, or building the actual solution. Your goal should be to mitigate the risk of offering a product nobody wants and needs, not to figure out the product details.
Having said that, it’s ok to address key UX and technology risks and evaluate important user interaction and architecture options as part of the strategizing work. But the bulk of the UX design, user story writing, and technology work should be done after you have successfully validated the problem.
To get your focus right, consider using a tool like my Product Vision Board to capture your idea, and identify assumptions and risks.
Do Just-Enough Strategizing Work
Minimise the amount of time you spend on any upfront strategy work to accelerate time-to-market. You should aim to get an initial, good enough product out as fast as possible, and then adapt it to the market feedback.
But don’t rush the work, and resist the temptation to jump start building the actual product. Explore the key assumptions and risks in your product strategy and business model by systematically testing and addressing them in an iterative fashion using, for example, observations, interviews, surveys, and prototypes.
If you can’t confidently state why people are going to use your product, who those individuals are, what makes your product stand out from the crowd, and why it’s worthwhile for your business to develop and provide the product, then you are not in a position to build the actual solution. Instead, continue the strategy work (persevere or pivot), or stop and move on to another product idea.
Talk to the Users
With all the product strategy work that needs to happen, it can be easy to lose sight of the most important success factor—the people who are going to use the product. There is no point in coming up with a smart business model and sophisticated user interactions, if you don’t understand the user needs, what they may struggle with, what works well for them, and what doesn’t. If the users don’t need your product or if they find it hard to use it, then you will find it hard to monetise it and achieve product success.
Therefore, get out of the building, as Steve Blank recommends, and meet target users face-to-face, be it online or onsite. I know that’s not always easy. But to succeed, I find it paramount that you—the person in charge of the product—carry out user research yourself and develop a deep understanding of the user needs.
When communicating with users, take a genuine interest in the people you meet. Listen attentively and let go of preconceived ideas about the problem you think the users have or the solution you believe they need. This allows you to discover what people really want and need thereby maximise the chances of creating a successful product.
Don’t Handoff Product Strategy Work
I’ve seen more than company where a group of people carried out the product strategy work and then handed it of to another group who would determine the detailed product functionality and deliver the product. But this practice is usually ineffective and wasteful, as it is likely to lead to misunderstandings and loss of knowledge—it is hard to precisely capture and pass on strategy insights in the form of documents, and written information is open to misinterpretation. In the worst case, the individuals tasked with delivery don’t understand and support the decisions taken during the strategy work, but do what they believe is right.
Therefore, ensure that the people tasked with the product strategy work also participate in developing the actual solution. The UX designer, developer, tester involved in strategizing should continue to work on the development team; the stakeholders who participate in the strategy work should continue to be involved and regularly attend product strategy and roadmap reviews, as well as sprint review meetings. This speeds up the product innovation process, creates a smooth transition from strategy to development, and avoids the issues mentioned above.
Consider Timeboxing the Product Strategy Activities
Knowing upfront how much time and effort will be required to carry out the necessary strategy work can be tricky, particularly when you develop a brand-new product and when you make a big change to an existing one, for example, to extend its life cycle. Luckily, there is a straightforward solution: timebox the work.
A time box is a fixed period of time, such as one week, that cannot be extended. At the end of the time box, the work stops, and you reflect on what has been achieved. If the work has not been completed, and your product strategy and business model still contain significant risks, you have two options: add another time box—and possibly pivot—or stop the work.
Consider holding weekly review meetings that involve the people carrying out the validation work as well as the management sponsor. Use the meetings to reflect on the risks that are being addressed and the learnings that you have achieved; consider the risks that still exist in your product strategy and business model; and decide if and how to continue.
Don’t Limit Product Strategizing to New Products
As your product grows and matures, its value proposition, market, stand-out features, and business model will change. To make and keep your product successful, it is paramount that you practice continuous strategizing and regularly review and adjust your product strategy, roadmap, and business model. These adjustments sometimes require little or no product strategizing.
But when bigger changes are required, such as taking your product to a new market or adding features and redesigning the user experience to sustain growth, you’ll likely have to carry out specific strategy work, as the picture below shows. If that’s the case, then I recommend anticipating the work and stating it on your product roadmap.
Modern product strategizing is hence best understood as a set of ongoing, continuous activities rather than a clear-cut phase that is separated by a milestone or gate from building the actual solution.
Post a Comment or Ask a Question
6 Comments
Hi Roman,
I enjoy reading your articles and thank you – I’ve gained so much knowledge! I am wondering when it comes to product discovery, is there a format that you personally follow to document it?
I’ve seen some team documenting it in plain text in a wiki pages, some use diagrams in between, some use tables to clearly point out what each individual in the team worked on which topic and in some cases, I’ve seen team using slides.
I want to know what’s your preference? Is there a template that you follow?
Thank you,
MS
Hi Mohamed,
Thank you for your feedback and question. I like to work with a tool like my Product Vision Board to capture the vision and strategy of the product and a Kanaban board to manage the product discovery work. (I explain in more detail how I use these tools in my book Strategize.) But I recommend that you use the product discovery processes and tools that work best for you. This may require a bit of experimentation. Additionally, ensure that you involve the key stakeholders and development team members in the work. This frees you from having to document all your decisions in detail.
Hope this helps!
Very good article on the MVP … I think to add it to the bibliography that I distribute to my students. Very clear, synthetic, all the qualities!
Thanks for your feedback Dominique. I am glad that you find the article helpful.
Informative as always. I am huge fan of you Roman. Have read all your books, articles and use product canvas the maximum in my projects
Thank you for your kind feedback Namrata. I am glad that you find my work helpful.