Skip to content

Tyner Blain - Scott Sehlhorst
Syndicate content This Feed Powered by
Software product success.
Updated: 8 hours 12 min ago

You Won’t Believe What These Five Lenses Can Show You About Your Product

Thu, 04/30/2015 - 08:01

three priorities of product management - desirability, feasibility, viability

Fundamentally, product management requires you to assess, synthesize, and prioritize the needs which drive the creation of your product in the context of three main objectives: desirability, viability, and feasibility.  While laudable, these objectives are too abstract to be actionable.  That’s where the five lenses come in (I could not resist the Buzzfeed-styled title).

The Product Strategy Grid

Steven Haines wrote The Product Manager’s Desk Referenceand from (the first edition of) his book I learned about the product strategy grid.  Over the years, I may have tweaked it to serve my needs, or used it a little differently than he presents – honestly, I don’t remember – but I believe that I am staying with the spirit of what he originally described for us several years ago.

As a product manager, we build roadmaps to help communicate to the team building the product, a set of instructions / goals / themes designed to manifest the product strategy. I believe the product strategy grid is a fantastic tool for

  • Aligning your organization around a definition of the product strategy, given the company’s objectives and perspective on the future
  • Clearly articulating the expectations the leadership team has – the measures by which “success” is defined for the product
  • Establishing an accountable expectation of the outcomes which are anticipated by the product manager for a given investment (aka roadmap)
  • Communicating a shared view of the future – beyond the immediate scope of delivery – with the entire team

The other day, with a client, I made this statement: I believe the product manager is entitled to know the measures of success, when being asked to build the roadmap.

The product strategy grid is too much to cover in a single blog post – even the long ones I tend to write.  I do a multi-day workshop to define what it means for a particular team.  Conceptually, I can walk an engaged and enthusiastic team through it in two hours.  I know this because I’ve tried (and failed) to do it in one hour.

For this article, I’m only going to talk about five lenses – the key to how I build out a product strategy grid (lenses translate to rows in the grid).  There may be better ways, but this one works.  Really works.  So thank you Steven for starting me down this path.

Five Lenses

five lenses on the keys to product strategy - customers, competitors, finances, technology, operations

Some day I may feel six lenses, or four lenses, to be better than five.  When using this technique at the portfolio level, I’ve used seven lenses to understand and assess not only the per-product context, but the context of the firm and how they take a portfolio of products to the market.  But for now, there are five.

I guess I should describe what I mean by the word lens.  This is the kind of corporate jargon that creeps into conversation and eventually shows up on someone’s meeting-bingo card. In this context, I mean a lens to be something you use to view your product from a particular perspective.  Some investments we make in a product are important because of their impact on our competitive position.  Other investments are important to reducing costs or achieving revenue goals.

elephant (thank you Deror Avi)

Applying lenses to how we view our product allows us to avoid the problem of the blind men and the elephant.  As an organizational bonus, it allows different stakeholders with specific areas of responsibility and interest to both contribute to the conversation, and develop a shared understanding of a holistic perspective on  the product.

Looking AT Each Lens

I’m not trying to tackle the full breadth and power of the product strategy grid in this article.  Each lens reflects a “row” in the grid.  There’s more stuff defining columns.

Let’s take a look at each lens.  One thing you’ll notice – some lenses have arrows pointing to two objectives (the competitive environment lens points to both desirability and viability), where some point to a single objective.  This is a reflection of my attempt to align lenses with the areas of focus in an organization by which people tend to have a sense of ownership of things.

Jeff Patton talks elegantly about reaching shared understanding (in User Story Mapping) – which is absolutely an intended outcome of using these lenses to organize views of the product strategy.  I also believe a team will be more effective when there are champions who feel deep connections with what everyone should look for (and see) through each lens.

Customer Environment

The customer lens is the one you look through when you are asking “who is my customer?” and “what problem are they trying to solve?”

When we talk about markets changing, targeting specific personas, and understanding problems, this is where we view the understanding we develop.  When discussing the inclusion of a particular feature in the product, we can look through through this lens and ask questions.

  • Would this feature help one of our target personas to solve a problem they care about?
  • To what degree of completeness / goodness / done-ness should we address this problem?
Competitive Environment

When you want to know if your product is “better” than your competitors, this is the lens you look through.

Conversations around relative market position, comparing our product with competitors happen here too.  We can ask specific questions here

  • What are the relative price and value of our product and our competitors products?
  • For the most important problem in our most important market, how does our product compare?
Financial Health of the Product

Being objectively better for our customers does not necessarily mean our product is “good.”  In investing, there’s a phrase – “a good company can be a bad investment.”  There’s an analog to be found in product management.

Our focus is on our customers, but it is not myopically so.  A product is expected to meet a set of financial objectives which justify investing in the product in the first place.  The specific questions being asked do vary from company to company.  They could be items like

  • What percentage of revenue is coming from sales of new products to existing customers, versus existing (subscription, maintenance, etc) product revenue?
  • What is the compound annual growth rate (CAGR) of our free cash flow?
  • What is our churn (or retention) rate for customers in the current year cohort versus last year’s cohort?
Technology Environment

This is a great lens for the champion of the technology team to stand up and say “we need to improve our capability to deliver capabilities” and have it make sense.

You can build a business on a house of cards, or shifting sand, or baling twine – or any other metaphor you desire for “it will all fall apart at some point.”  It would be nice to know when it will fall apart.  It would be even better to change this state (and know it), or prevent it from happening at all.  Interesting questions tend to be a function of “what specifically has been hurting us recently?”

  • What percentage of our investments in quality (e.g. cost of quality) are reactive, versus proactive?
  • How many versions of the product are we simultaneously supporting in the field?
  • What is the 90% time* for customers getting fixes to sev-1 and sev-2 bugs deployed in their environments?

*90% time is the time by which 90% of all fixes have been deployed.  The average time is not nearly as reflective of how well you are serving your customers.  Also note that the measurement is from “reported by customer” to “resolved for customer” and not “validated by QA” to “promoted to trunk by dev.”

Operational Performance

In enterprise software, it isn’t enough to build software, you have to deploy it.  That might take months.  You might be building a business on which the ability to scale is a key assumption of the business case.

The outside-in notion of understanding how your customer defines success (at solving the problem for which they would be using your product) has a nice home here.

You can ask questions like

  • How many man-weeks of effort and calendar-weeks of time are required to deploy the product? [This is another great place for the 90% time]
  • How much faster must our customer’s invoice-processing process be, for them to consider themselves successful?

Each lens provides a perspective on aspects of the product strategy, always relevant to everyone – and often particularly relevant to someone specific.  Combined, the lenses provide the context in which a product manager makes their investment decisions.

The team relies on the product manager to “give them a backlog” and assumes the backlog is identifying the right things to be building.  The definition of right things is a function of product strategy.

How do you know if you have the right product strategy?  The answers are visible through these five lenses.  Now do you believe what they can show you?

Categories: Blogs

Features do not a Product Roadmap Make

Tue, 04/07/2015 - 23:32

list of features

Last month, Mike Smart of Egress Solutions and I gave a webinar for Pragmatic Marketing on product roadmapping when working in agile environments. We had a great turnout of over 1500 people in the session – with not nearly enough time to answer all of the questions.

One attendee asked, “Please explain how a prioritized list of features is not a roadmap?

A fantastic question, which we did not see in time to answer during the call.

Why and What and When

The shortest answer I can come up with for the question – and probably all we would have had time to address during the call is the following:

A roadmap tells you both “why” and “what;” a list of features tells you only “what.” #prodmgmt


If all you need is the answer above, then this is a really short article for you – you can stop here.  There is some nuance to the above statement, which helps you address something more valuable – having a good roadmap.  If that’s interesting, then keep reading.

Which What?

Seven years ago this month, I joined in the fracas stirred up by an article where the author

  1. Described something (bad) which was not a roadmap
  2. Called it a roadmap, then
  3. Concluded that roadmaps are bad.

I would describe the author’s complaints [about roadmaps] as a list of things which can go wrong when you treat a list of features as if it were a roadmap.

Seven years later, this is still a source of confusion.  Perhaps it is the logical conclusion of anointing people with the title of “product manager” and not giving them the training, tools, and mentorship needed to learn the craft while simultaneously doing the work.

Some of the confusion may come from how we talk about roadmaps.  My tweetably short answer above leaves something to be desired.

Roadmap vs Backlog

All of the different containers for requirements document “what” the team will be building.  The different containers do this in different ways – and the roadmap has a qualifier.

  • PRD – identifies all the things which the team will build*, and the context in which those items are relevant or organized (e.g. the “Shopping Cart” section of the PRD for an ecommerce website will include the requirements for including controls that allow a user to update the quantity of items in the cart).
  • List of Features – possibly the most abhorrent of the containers – in the midst of a long list, will be the requirement to include an “update quantity” control with every item in the shopping cart.  If you’re lucky, the requirement will be tagged with “shopping cart” for ease of organizing / tracking progress.  Given the lack of context provided by a list of features, this requirement might be preceded by the “update inventory levels” requirement and followed by the “update user profile picture” requirement.
  • Backlog – when someone takes a list of features and sorts them by “give me this first” you get a backlog.  The story at the top of the list may be “As a [shopper in a hurry, who is multitasking while waiting in line at the DMV] I need to be able to update the quantity of items in my shopping cart because someone jostled me and I double-tapped my phone when I meant to single-tap, so that I only purchase the quantity I intended.” The question too many people are happy to dodge is why is this story at the top of the list? We’ll have to come back to that another time.
  • Roadmap – “Yes, but” is consultant speak for “I’m answering your question, but let me tell you the question you should have asked – and the answer to that question as well.” If your roadmap says “Will include update quantity control in shopping cart” you’re doing it wrong.  Your roadmap should say “Improved shopping experience on mobile” or “Better shopping experience for spearfisher  persona.” Those descriptions of “what” are at a higher level, and articulate intentionality.  So, yes, a roadmap includes “what” – but not the same “what” as a backlog.

*As an aside – the team won’t actually build all of the stuff in the PRD, nor will they build what they build when the PRD says it will happen, and it will be over-budget.  But that’s another discussion entirely – and a big part of why “agile” came into existence in the first place.

When a roadmap is being used to communicate “what” the product will be, it should be in the language of describing which problems will be addressed, for whom, or in what context.  This is the most important type of theme which would be part of a thematic roadmap.  Other themes could be “improve our positioning relative to competitor X” or “fill in a missing component in our portfolio strategy.”

Context in Design

Requirements, by their nature, live in a particular context.  At one elevation or perspective, something is a requirement, defining and constraining what must be done; in a different context, that same something is a design choice representing a choice about how to do what must be done.

Several months ago, Andy Polaine posted a presentation about the future of UX, in which he presented a compelling imagery establishing the context in which design decisions are made.

Andy Polaine context slide

To fully appreciate the power of what Andy is talking about, I believe you have to view the above slide (#55), in the context of his presentation.  After experiencing it that way, the imagery has infused itself into how I frame product management activities.

If you cannot make time for now, the metaphor still works – solving the “visible and available” problem happens in the context of a wider environment (a larger, more complex problem), which is itself in the context of a wider environment, etc.

I find that I also apply the same concept when thinking about investments across differing time horizons.

On a given day, a member of the product team is implementing the code for adjusting the quantity of an item in the shopping cart.  Implementation is not the rote mechanical movements of a machine – it is a series of choices and actions.

Those implementation decisions happen within the context of implementing a story from the top of the backlog – helping someone place orders on their phone while waiting in line somewhere.  This context informs choices (like not requiring a modal dialogue to confirm the user’s choice when making a change in quantity, or making the change to “quantity of zero” be an explicit and distinct interaction).

The decision to prioritize empowering mobile users this quarter comes within the context of a decision to focus on 18 to 26 year olds as a key demographic for our product sales.  Improvements to the mobile shopping experience happen in conjunction with a change in inventory, a partnership with another company, and a targeted advertising campaign.

The focus on this particular group of customers is a “business design” choice as well.

Context in Agile A backlog lives within a roadmap, it does not replace it #agile #prodmgmt


A similar perspective on context is presented by Mike Cottmeyer of Leading Agile when looking at how you put the work the teams are doing into context. A “release backlog” or “product backlog” is defined within the context of strategy – which is manifested in the roadmap.

strategic agile context

Mike’s slide (#92 in a great deck) stops with “strategic” context for a release.  He and I have talked about this, and I believe we have strikingly similar views on context.  This view marries both the time-horizon and the problem-definition notions of context, from the perspective of the person doing the work and understanding the “why” of doing the work.

Within each context is framed a set of choices – providing both boundaries and flexibility to adapt to what we learn, but at a lower level of detail, with less ultimate potential value, for a shorter period of time.


A backlog – a prioritized list of features – is not a roadmap.  It is a reflection of a set of design choices which happen to fulfill in product what the roadmap sets out as a manifestation of strategy.

A roadmap tells you both “why” and “what;” a backlog tells you only “what.” #agile #prodmgmt
Categories: Blogs