Establishing an Effective Product Strategy Process
Establishing an Effective Product Strategy Process
Organizations that ercognize the benefit of mapping and following a product strategy are able to iterate on the fly while maintaining a controlled roadmap.
Join the DZone community and get the full member experience.Join For Free
Why a Product Strategy Process Matters
An effective product strategy process should ensure that a valid product strategy and an actionable product roadmap are always available — that a shared and valid approach to achieving product success is available at any time, as the picture below illustrates.
In the picture above, the product strategy describes how a visionary, inspirational goal is attained. It includes the product's value proposition, market, stand-out features, and business goals. The product roadmap shows how the product strategy is put into action by stating dates, measurable goals, and selected features. It provides the context for making the right tactical decisions including prioritizing and managing the product backlog.
Having a valid strategy and actionable roadmap available at all times requires two complementing strategizing approaches, a timeboxed and continuous one, as I explain below.
Whenever you create a brand-new product or make bigger changes to an existing one, you will benefit from creating and validating a new product strategy. This is best done as part of a dedicated product discovery period that also investigates crucial user experience and architecture risks. This results in an innovation process like the one shown in the picture below.
Please note that the picture above depicts product discovery and product development as sets of overlapping activities rather than distinct phases or stages: carrying out some development activities like UX design and high-level architecture as part of the discovery work sets up the development work and avoids having to use a sprint 0.
As it's hard to correctly determine upfront how much time will be required to carry out the necessary discovery activities, for example, observing and interviewing users, testing prototypes, and validating pricing assumptions, I like to time-box the work. If you are not sure which time box is right for you, then start with one month and hold weekly review meetings where you assess the progress and decide if and how to continue.
In addition to allocating enough time for focused discovery and strategy work, I find it helpful to adopt a collaborative approach. Bring together the right people and form a product discovery team. You will need development team representatives like a user experience (UX) designer, developer, and tester, key stakeholders such as a sales rep, marketer, and support person, and a Scrum Master, as the following picture shows.
A collaborative approach offers you several benefits: It leverages the knowledge and creativity of the dev team and stakeholders, creates a shared understanding, and builds strong buy-in. This reduces risk that the dev team and stakeholders don't understand or support the product strategy. Don't forget, though, that you lead the strategizing effort. This includes making a decision if no consensus can be reached. The other discovery team members should help you create and validate the new product strategy, and the Scrum Master or Agile coach facilitates the process.
Make sure that the people involved in the discovery work continue to be involved as the focus shifts to developing the new product or features. The development team members should remain on the dev team; the stakeholders should continue to play their respective roles and be involved in reviewing and adjusting the strategy.
As helpful as it is to create a product strategy, it is not enough. The world doesn't stand still; markets and technologies change; new competitors emerge. It is therefore important that you regularly assess if your strategy is still working:
- Review the product performance using the appropriate key performance indicators. Analyze the data collected to understand how your product is doing. Do the metrics show a positive, flat, or negative trend? What conclusions can you draw from the analysis? What would help your product perform well?
- Look for new market trends. Are there any new technology, regulatory, or social developments, for example, machine learning, GDPR, and gig economy? Do they impact your product? Do they offer an opportunity to innovate, add, remove, or enhance features, or create a brand-new product? Talking to users, attending trade shows and conferences, and participating in online communities can help you spot new trends.
- Keep an eye on the competition. Are your competitors launching new products or features? Are there new market entrants? Should you respond to the changes? If so, which actions are appropriate? Job postings will help you guess your competitors' plans. Reviewing their products will tell you if your product is still sufficiently differentiated.
- Follow developments at your own company: Are there any changes to the business strategy? And if so, what are the consequences for your product? Are important stakeholders less engaged? Is their interest and support weakening?
To help you effectively carry out the work above, I recommend the following:
- Block at least one hour per day in your calendar for strategic work.
- Schedule collaborative strategy reviews on a regular basis-once per quarter, as a rule of thumb.
Carrying out strategic work on a daily basis helps you avoid nasty surprises such as a competitor offering new killer features. It makes it more likely that you recognize 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 actions early.
In addition to the daily strategy work, the quarterly reviews assess the product strategy and product roadmap taking into account longer timeframes and larger trends. By involving development team representatives and key stakeholders-ideally the same people who helped you create the current product strategy-you leverage people's collective creativity and knowledge, create alignment, and mitigate the risk that the individuals don't support the strategy changes.
While scheduled strategy reviews are helpful, you should, of course, not wait for the next review if your daily strategy work shows that there are developments that need to be urgently discussed with the dev team and stakeholders. Instead, hold the next collaborative review as soon as possible.
Making It Stick
"In theory, there is no difference between theory and practice; but in practice, there is," Yogi Berra once said. I find this insight is particularly applicable to product strategy. Many organizations are great at the tactical level but not at systematically creating, reviewing, and adapting the product strategy. This has two common causes:
- Lack of empowerment.
- Product people being too busy.
Unfortunately, not all companies recognize that strategic responsibilities are a mandatory part of a product person's job. I have seen more than one business where product people were great product backlog caretakers but lacked the authority and knowledge to make strategic product decisions. If that's the case for you, then I recommend two things: lobby for more management support and educate yourself. The more you know about product discovery and strategy, the easier it will be for the decision-makers to trust you to own strategic product decisions.
Additionally, product people sometimes take on too many responsibilities. A common mistake is to perform Scrum Master duties, like facilitating teamwork and looking after the development process, for example. This makes a demanding job even more challenging and it increases the workload. You should, therefore, ensure that you focus on your actual job, say no to other duties, and free up enough time for strategy work. Don't allow urgent tactical tasks to take up all your time but make strategy work a high priority.
Published at DZone with permission of Roman Pichler , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.