Product strategizing describes the activities required to determine if and why a product should be developed and offered. This increases the chances of creating a product that users actually want and need and achieving product success, and it involves answering the following questions:
In order to answer the questions above, you may want to use techniques such as direct observation, user interviews, prototyping, creating a strategy canvas or E-R-R-C grid, and you may capture some of them using a tool like my Product Vision Board. Whatever you do, I suggest that you follow Steve Blank’s advice and “get out of the building”. Meeting users and customers, at least in the form of a video call, not only helps you validate your assumptions and develop new ideas. It also allows you to empathise with the individuals and to better understand their perspectives and needs.
I find it helpful to distinguish two types of product strategizing: timeboxed and continuous discovery. Let’s look at timeboxed strategizing first.
Whenever you create a brand-new product or when you make bigger changes to an existing one, like taking it to a new market, you will benefit from using a dedicated, timeboxed product strategy period. This results in an innovation process like the one shown in the picture below.
In the picture above, the product strategy work precedes product development. The former focuses on understanding if and why a product should be created or updated. The latter largely determines how the product should be developed. This includes discovering the right UX design and functionality and making the right technical decisions.
Note that I have purposefully drawn discovery and development as overlapping, as I find it helpful to address major UX and technical risks as part of the strategizing work—without making the mistake of using big design upfront (BDU). Addressing these risks ensures that the development team has the right knowledge to hit the ground running when starting development. Consequently, the key deliverables include the following:
As it’s notoriously difficult to correctly forecast how much time a bigger piece of strategy work will require, I recommend timeboxing it. To do so, consider the amount of innovation and risk present and allocate an appropriate timebox. If you were to develop a brand-new product for a new market with new technologies, for instance, then you would face more risks compared to taking an existing product to a new market. Consequently, the former will require more time than the latter. You might want to allocate, say, two months for the first initiative, but only two weeks for the latter, assuming that you already serve the new target market. Additionally, I recommend running weekly review sessions to understand the progress of the discovery work and adapt it if necessary.
To carry out the strategizing work, bring together the right people, product person, development team representative, key stakeholders, and Scrum Master or agile coach, as shown in the picture below.
As the person in charge of the product, you should lead the strategizing and development effort. Here’s why: You can’t be responsible for maximising the value a product creates if you don’t actively participate in, guide the discovery work, and shape strategic product decisions.
Development team representatives—ideally a UX designer, one or two developers, and a tester—should also engage in the discovery activities. This leverages the individuals’ knowledge and creativity; it surfaces feasibility issues and technical risks; and it allows the team members acquire knowledge about the market and users and understand why the product is being created or updated. The latter will enable the development team to make the right design and technical decisions and own the solution. Do make sure that the individuals continue to work on the team in development and help build the product. Otherwise, you are likely to lose precious knowledge and time.
Inviting the key stakeholders to participate in the product strategy work ensures that their ideas and concerns are taken into account at an early stage; it takes advantage of their expertise; and it maximises the chances that they will support the resulting strategic product decisions: When people are given the opportunity to contribute to a decision, they are more likely to understand and buy into it.
The Scrum Master or agile coach, finally, should facilitate the discovery process and the meetings in order to ensure that everybody is heard, and nobody dominates. This may include suggesting applying a Kanban-based process to visualise and manage the discovery and strategy work, as I recommend in my book Strategize.
As helpful as timeboxed product strategizing is, it is not enough. Here is why: When you create a brand-new product, you typically aim to launch a minimum viable product (MVP), a good enough offering that addresses the early market. To achieve product-market fit and make the product successful, more discovery work is required: You now need to figure out how to adapt your product to serve the needs of the mainstream market. But even once you’ve entered the growth stage, you can’t afford to neglect the product strategy. The world doesn’t stand still: Markets and technologies change, competitors improve their products, and new market entrants may appear.
Product management is therefore like riding a bike: When I am on my bike—which is one of my favourite pastime activities—I have to turn the cranks, change gears, steer the bike, and so on. But if I forget to look ahead, I’ll sooner or later get lost or even crash. The same is true for your product: If you are completely immersed in execution and forget about discovery, you’re likely to miss an opportunity or threat and experience difficulties further down the line.
It is therefore important that you carry out continuous strategizing. This includes the following activities:
To help you answer the questions above and carry out the related work, I recommend the following two measures:
First, block at least one hour per day in your calendar to carry out the necessary product strategy work. This helps you avoid nasty surprises, such as a competitor leapfrogging you by offering a new killer feature, and it makes it more likely that you recognise early warning signs like declining sign-up rates, increasing churn, or a growing number of support calls. This allows you to be responsive and take action early.
Second, regularly hold collaborative strategy reviews, once per quarter, as a rule of thumb. Assess the product strategy and product roadmap together with development team representatives and key stakeholders. These are ideally the same people who participated in the timeboxed discovery work and who helped you create the current product strategy and roadmap. As mentioned before, involving dev team members and stakeholders leverages their collective creativity and knowledge, creates alignment, and mitigates the risk that the individuals don’t support necessary strategy changes.
If you manage a larger product and you work in a scaled environment, don’t forget to involve the other people who look after the product, for example, feature and component owners or SAFe product owners, in both timeboxed and continuous strategizing.
In addition to the collaboration benefits already mentioned, this makes it more likely that strategic decisions will be translated into tactical ones, and it ensures that tactical insights—like the knowledge gained from analysing user feedback on specific features—inform the strategic decisions.
It may not be pleasant to experience, but conflict is necessary to innovate successfully. Without…
Developing a winning product strategy is hard. Keeping the strategy relevant and achieving continued product…
The product roadmap is a popular product management tool that communicates how a product is…
The product strategy is probably the most important artefact in product management. But how do…
A product team is a cross-functional group whose members work together to achieve product success.…
The most amazing product strategy and product roadmap are ineffective if the stakeholders don’t support…
View Comments
Hi Roman,
First things first - big fan! I recently finished reading your book Agile Product Management with Scrum. Every time I read an article by you or an expert in PM, I uncover a new learning which is amazing. That being said, I’m working on a product that was developed to an extent and stopped. I am now the new PO to take this product forward. Being in the middle of knowledge transfer process, I’d like to understand the things I should keep in mind during discovery, strategy and roadmapping. I know the organisation will have their input. But your thoughts will also help learn and be prepared. Thank you in advance. Call me Nathan. :)
Thank you for sharing your feedback and question Nathan. When you take on an existing product I recommend that you:
Hope this helps!
Hi Roman, you've mentioned a validated product strategy and business model is a "deliverable" of the product discovery work, but in order to obtain development team resource and assemble the correct stakeholders would you agree that some of this work will already need to have been completed, making it a "pre-requisite" for discovery (rather than deliverable)? I'm particularly thinking about scenarios when doing product discovery for disruptive innovation type projects (assessing business opportunities) way before a development team is required.
Hi Luke,
Thank you for sharing your question. My intention was to recommend assembling a cross-functional team in order to assess a business opportunity and investigate an idea. This team should consist of the person in charge of the (future) product, key stakeholders, and development team members, like a UX designer, developer, and tester. In the case of a brand-new product, the latter should become members of the team responsible for building the actual product.
To make this approach work, development organisations have to reserve capacity to support innovation/discovery initiatives; developers no longer just implement requirements but help test business ideas. I am not the first one to suggest such an approach btw. Marty Cagan, for instance, suggested in a video published in 2011 a similar setup. Note that the development team members don't necessarily have to be involved full-time in the discovery work; part-time is often sufficient.
Having worked for and with a number of large entreprises, my personal experiences with the traditional approach of using a dedicated research group that assesses business opportunities and carries out technology development work has been poor. Even if the group understands the market needs and the capabilities of the development, marketing, and sales organisations, the resulting handoffs usually cause a loss of valuable knowledge. The integrated, cross-functional approach I sketch in the article tries to address these issues.
Does this help?
Thanks Roman. It does...and FWIW i'm totally bought into the idea of cross-functional teams 100% + reducing handoff's..but i'm wondering what you would consider to be the prerequisites for starting the discovery, other than just an idea? In my experience big organisations are not short of ideas but often fail to know how/where to start. So in your opinion where does discovery begin and how is it initiated? (Apologies realising my example may be a bit too nuanced for this comment thread!)
Glad my answer was helpful Luke and great follow-up question! I view an idea generation and selection process as the prerequisite for product discovery. Such a process evaluates ideas for new and significantly enhanced products, often according to strategic fit. This ensures that the idea is aligned with the business and product portfolio strategy. The input of product discovery is therefore an idea, typically one that has been evaluated. Do you agree?