Demystifying product strategy

strategy-image

Since “strategy” can mean different things in different situations, here’s a definition of how I think about it related to product management:

Finding efficient ways to achieve the company’s goals through product solutions

Another way to think about it is:

Finding ways to maximize value at minimal cost

A good product strategy can give you a leg up in a race against the clock (or the competition), and it can increase the odds of your team and company being successful.

The maximize value part

This comes down to translating company/business objectives (including key metrics / KPIs) into a product plan that helps the company achieve its goals.

Product folks are tasked with helping their company achieve its goals while also helping customers (aka, users) achieve their goals, and while also keeping their team informed, efficient, and motivated to get it all done. (Project managers or other roles in an organization can also help a lot, but these roles don’t always exist.)

Sometimes, there’s a clear path for how product work can help the company achieve its goals, such as when an integration with a partner can propel a business strategy. Other times, the team needs to explore possible solutions to meet the company’s goals, which factors in:

  • Customer needs discovery/analysis
  • Team brainstorming (including exercises such as whiteboarding/sketching)
  • Research/testing with customers

After this, solutions need to be designed, built, tested, and released.

After releasing something, it needs to be measured and potentially iterated on to build out further or to optimize.

I could write posts to cover each of these steps, but in a nutshell, this is what needs to be done in order to maximize value. Depending on timelines and resources, you might be able to skip some steps, or at least move through them faster, while still achieving the goals (and perhaps revisiting in the future for further improvement). In general, I’ve found that it’s more important to be practical with how you go about things than to try to follow a process according to every detail as it’s written in a book.

The minimal cost part

There can be several types of costs with product work, including:

  • Dollar cost – You might need to pay for a technology or service to achieve a solution, or you might need to hire people. These are straight dollar costs.
  • Time cost – It takes time from one or more team members to do anything, which can be equated to the dollars that the company spends employing those people for their time. For example, if the company spends $50 per hour on an employee, and if it’d take 10 hours for the employee to complete something, then the cost of having that employee do this work is 10 hours of time which you could equate to $500.
  • Opportunity cost – This comes down to prioritization. In general terms, if you work on Option A now, then Option B might be postponed until Option A is done. The expected gains from Option B (which could be postponed) is an opportunity cost of Option A. For example, if a $10,000 gain is expected from Option A while a $5,000 gain is expected from Option B, then you might prioritize Option A over Option B. In this case, Option A brings an opportunity cost of $5,000 (i.e., expected gain from Option B), which is generally okay because it’s less than the expected gain from Option A (i.e., $10,000).
  • Team dynamic cost – This can be harder to quantify than other costs. On a high level, if your team is happy, motivated, and efficient, they’ll be positioned to do well (assuming they’re working on the right things and helping the company succeed). The challenge is maintaining a positive environment for the teamwork, which includes communication, collaboration, celebrating wins, learning from issues, and making it clear that it’s ok to discuss struggles or suggestions for the benefit of everyone (doing sprint retrospectives is one way to facilitate this). Some situations bring more pressure than others, but always remember that you’re part of a team that comes to work every day to solve problems, so tap into that in a supportive and collaborative way.

An example of where to apply strategy

Do multiple current customers, prospective customers, current partners, or prospective partners have similar needs? If so, you might be able to leverage a new product capability that can provide value across a broad spectrum of users / entities. In other words, doing a single body of work that results in more than one win is a strategy that could be explored.

Things that can help think through strategic opportunities

1. Create a product plan (roadmap) 12 to 18 months in advance

  • Break it down by quarters (e.g., Q3 2017, Q4 2017, Q1 2018, Q2 2018, Q3 2018, Q4 2018)
  • You only need to think about high level items (i.e., a new product/app or major new capability of an existing product/app) for the periods that are between 6 and 18 months away
  • Be more detailed with items for the periods up to 6 months away
  • Keep in mind — and include an explicit note on the roadmap — that roadmaps change based on shifting priorities and new learnings (about customer needs, partnership opportunities, etc). You want the roadmap to be seen as directionally correct, but fluid based on the company’s shifting priorities (or significant shifts in what’s learned from the market, such as customers or competitors).

I’ve used a few different roadmap formats over the years and currently employ the following two for different purposes:

Template A:

(this is good for high-level discussions around significant high-level deliverables)

 

Roadmap Template A

Template B:

(this is good for mid-level discussions that gets more detailed than Template A)

Roadmap Template B

Template B also helps to facilitate update meetings with any stakeholders about progress, what’s been accomplished, if there are risks or dependencies, etc.

Beyond Template B would be a backlog that gets very granular (often tracked in software like Jira, Trello, or some other project/task management tool), which typically only needs to be reviewed with scrum team members (e.g., developers and QA).

(I’ll save for another post why it’s better to have a goal-based or theme-based roadmap than a feature-based roadmap.)

2. Meet with your company’s executive leadership team (e.g., CEO, CTO, the heads of Marketing / Sales / Business Development / Customer Experience)

The main goals are to:

  • Recalibrate on business priorities
  • Make sure that executives across the company understand what’s been happening with the product and what the vision and plans are for the future

At some companies, it’s easier said than done to get executives in a room together, so you might need to sell this kind of meeting in advance by setting expectations for what’s going to be covered and what the goals are (which should clearly sound beneficial to the company as a whole and also to each department)

Conclusion

Strategy is a skill that can be developed over time. The more you think about it, work through exercises, collaborate with others, and read about examples, the better you’ll get. Just always keep the main purpose in mind: finding efficient ways to achieve the company’s goals and finding ways to maximize value at minimal cost.

This entry was posted in Product Management and tagged , . Bookmark the permalink.