Skip to content

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

Product Owner Manager – Alone Together

Wed, 04/13/2016 - 05:30

thumbnail of venn diagram

Product owners and product managers.  Two roles, often done by one person.  Together, the product people need to take an organization’s strategy, figure out the appropriate product strategy, and convert that into actionable work for the delivery teams to create the right product.  What does the product manager own, and for what is the product owner responsible?

Product Management Overlaps

A month ago, I was asked how to think about splitting the product owner and product manager roles and responsibilities by one of my students.  I drew a Venn diagram on the whiteboard and talked through my thinking on the subject.  This was a sidebar conversation, then we returned to the lecture topic, and I moved on.

Yesterday, I was reading an article about the overlap between product management and user experience, by Melissa Perri, who has feet in both worlds.  She drew a Venn diagram showing the unique and shared areas of responsibility and interests.  As an example, she shows customer problems as a shared responsibility.  I agree and incorporate the same perspective in my models of software development.

More specifically, the way I frame the collaboration between UX and product management – specifically for customer problems – is that I believe

  1. The user experience person is responsible for developing the point of view of which problems are most important to our customers.  They develop the deepest understanding of context, motivation, and capabilities; as well as user goals.
  2. The product manager is responsible for prioritizing the user goals in the context of all of the other goals that manifest as product strategy.  The product manager is bringing in the perspectives of competitive positioning, additional stakeholders and ecosystems, organizational capabilities, etc., and folding user goals into the bigger picture.

Melissa’s article is a good one, you should go read it.  She also talks about the challenges that arise from wanting to be a multi-disciplinary player on a team with rigid boundaries.  In addition to enjoying her article, and thinking more about the overlap of product with UX – and seeing her Venn diagram – I was reminded of a similar diagram I drew in March.

Product Manager and Product Owner

product manager and product owner Venn diagram[larger version]

[Ed: Product Manager is on the left, Product Owner is on the right]

The way I positioned these two roles was to acknowledge two “truths.”

  1. These are both (more than) full time jobs.  A product manager never runs out of valuable work to do – the market is always changing, there is always more to learn – and more to do based on what she’s learned.  A product owner never runs out of valuable work to do either.  Being downstream of continual learning means being the recipient of change – and that doesn’t even touch on the full time job of collaborating with the engineering and quality teams.  The two jobs cannot be done exceptionally well without two people sharing the work.
  2. Most companies only staff a single person to do the work.

We all commiserated a bit about this – and agreed that the survivable approach is triage – spend the limited time you have on the most important things.  A product manger or product owner must thrive in ambiguity and make the right calls about when “good enough” is, or isn’t, good enough.

A T-Shaped Team

The letter T

I generally find that the most effective individuals are the ones who are T-shaped.  They have breadth of perspective, knowledge, and context (the horizontal of the T).  They also have depth of insight, experience, and expertise (the vertical of the T).

In the product space (much easier to type than “the product management and product ownership space”), we can extend the metaphor to be three dimensional – and what is required is a balance of three perspectives

  1. A time horizon that looks out beyond the next few releases.  How will we manifest our organization’s strategy through product?  What role should (this) product play as part of a comprehensive strategy?
  2. A breadth of understanding of the market. Understanding the context in which the product has to compete to be successful.  What problems are most important to be solved, for whom?  How do we differentiate?  What is our strategy for right now?
  3. A depth of insight and excellence at execution.  What precisely does it mean to solve this problem, for this customer.  How will the team know that what they built is actually what is needed?

While it is possible to find someone who has strengths in all three areas, I believe the best chance for success is to have two T-shaped people, who share an understanding of the market, and divide and conquer in the ways they apply this understanding.  The product manager leverages an understanding of the market to develop hypotheses and strategy for the future.  The product owner leverages an understanding of the market to drive effective specificity in the product of the present.

When I’ve been responsible for doing both, I try and subconsciously change hats when I change perspectives.  It might be a waste of cognitive effort, but it seems to help me. YMMV.

Shared Space Ownership

product manager and product owner Venn diagram[larger version]

In the diagram above, there are a couple items squarely in the product manager side of the Venn diagram.  The decision about which market(s) in which to compete, is a decision made on the longer time horizon.  It isn’t something that would change sprint-by-sprint, or release-to-release.  Adding incremental markets, in sequential releases, as an intentional strategy can make sense.

Perhaps to greater benefit, a product manager can drive focus by specifying where the product will not compete. Focus is the glue that binds products together.

At the same time, there are items particularly suited for product ownership – as a practice and aptitude, regardless of role or title.  Transforming metrics of user success into measures of product requires melding insight of what and how with understanding of why.

Understanding how a customer defines success is something both product manager and product owner must know.  After working with many teams over the last few years, I believe there is only one right answer about who should own this, and who should participate.  And the answer is…

Given two people, one of them will be more available or more able than the other.  That person should do it.

Sorry there isn’t a silver bullet – if there is a silver bullet, it is to base your decision on the specific people involved, and not some formula spouted by a well-meaning organizational designer.  This is, of course, the approach to apply to all the items you might do, not just the 7 I included in the diagram.

While we’re at it – user experience is heavily involved in understanding how a customer defines success at solving a problem.  Perhaps we should work with Melissa to develop a three-lobed Venn diagram.  Did your employer staff UX, product management and product ownership on your agile team?

Categories: Blogs

Encryption is not Binary

Thu, 04/07/2016 - 05:38

Kano model - more is better - depicting 'good enough' as a concept

If you ask someone if they require encryption on their device, first of all, you will likely get one of two answers – yes or no – useful for segmenting your market or developing persona.  If you’re lucky, you’ll get a better answer – “you’re asking the wrong question!

Be Outside-In, Not Inside-Out

Inside-out thinking is taking your current view of your product (or product-to-be), and mapping it to the problems you discover in the market.  By contrast, outside-in is to understand problems your prospective customers face, and build viable solutions to those problems.

People don’t require encryption, they require protection of information.  You could achieve that protection through encryption, or by embedding your device in epoxy, or keeping it in your pocket at all times.

As an example, in 2008 the iPhone 3G’s user storage was not encrypted.  Data Protection was provided by unlocking the user interface to the phone with a PIN code.  The expectation was that you had to use the interface to access the stored data, so by protecting the user interface, the data is protected.  Without encryption.

Inside-out thinking is being an order taker, providing what is requested, not what is needed.

Outside-in thinking is recognizing that people want to protect their data from others.

Outside-in thinking might even re-frame the problem as one aspect of a need for privacy.  It just depends on what context in which you are defining the scope of the problem you wish to solve.

Applying Kano to Data Protection

Kano analysis is one of the key components of what I teach in DIT’s product management program every spring, and will also feature in one of the sessions of Product Owner Survival Camp in May 2016.

At first glance, what seems obvious in 2016 is that data protection – from the point of view of the user – can be classified in one of three ways

  1. must have data protection on my device
  2. must not have data protection on my device
  3. I am indifferent about data protection being available on my device

While the Kano model supports the notion of requiring that a feature not be present I have not found it useful yet in a product management context.  Partly, I suspect, because with an outside-in perspective, you aren’t looking at the presence or absence of features, you are only looking at capabilities – and I haven’t found a product where the concept of “I would have bought it, except someone could use it to do this other thing I don’t like, so I will not buy it.”

It is possible, in some markets, that the ability to protect data would be a delighter.  In those markets, the capability would be disruptive.

Data Protection, however, is not a boolean capability.  There are degrees of protection.  This implies that there is a notion of good enough protection of data. What might that look like?

Good Enough Data Protection

Building on a rapid refresher of first principles of applying Kano modeling as a product manager, we start with a realistic view of the more is better characterization of problems.

More is better Kano model - including diminishing returns[larger version]

The notion of good enough is added to the model.  There is some level of security that a user perceives about their data (using slightly more outside-in language), as a function of how well it is protected (outside-in), utilizing whatever technology (inside-out) the product happens to use.

Below this threshold, a user will be unsatisfied, and above the threshold, the user will be satisfied.  When we’re defining an MVP, we need to make sure we satisfice the user.

We want to aim for viable, not just minimal with our product.


A common source of product failure is delivering incomplete solutions to problems.

Adding some illustrative data points to the model, we get the following:

data security diminishing returns kano model[larger version]

The degree to which you need to solve a particular problem is defined by your users.  It may not simply be a Boolean decision (“is data protection a capability?”), it may be a scale of increasing capability (“how much data protection is provided?”).

In the security space in particular, there is the added complexity of deciding if you need to provide legitimate security, or the perception of security, or both.  Then you have to decide what that means in the context of your market, customers, competition, and product.


While the debate surrounding the current encryption & phone-unlocking controversy can be interesting, the lesson for product managers is that there is value in understanding how your users frame the problems you hope to help them solve.

Approaching your product from the outside-in – from the perspective of understanding what your users value, is critical.

Framing, or characterizing, the problem the same way your users does will help you determine when good enough is actually good enough.

Categories: Blogs

Product Owner Survival Camp

Wed, 03/30/2016 - 17:59

Product Owner Survival Camp 19-20 May, Cambridge, MA

Product owners are likely to find themselves alone in the organizational wilderness. Their organizations expect them to connect the towers of long-term strategic planning with the frontiers of great new products. Iterative and incremental development of solutions can bring these two worlds together. There’s always a gap between strategy and execution – and product owners are ideally positioned to help fill that gap.

What we need is a survival guide – a set of principles, tools, and techniques; learned and applied in a two-day “camp” with industry-leading experts in agile product management and product ownership.

Announcing Product Owner Survival Camp, USA – Cambridge MA 19-20 May 2016

Ellen Gottesdiener, Jeff Patton, and I (Scott Sehlhorst) have developed Product Owner Survival Camp USA to address exactly this challenge – helping product owners close the gap between strategy and execution.

Jeff Patton, Ellen Gottesdiener, Scott Sehlhorst - POSC Instructors

Building on the successful program developed and delivered in Europe in 2014 and 2015, we have designed this program to serve the needs and goals of product owners. We are bringing real-world expertise in agile product management and product ownership to you in this unique, action-packed program. You will learn ways to close the gaps between strategy and tactics. You will elevate your ability to discover the right product for the right customer at the right time, and tap into your product ownership leadership capabilities.

We’ve framed out major elements in closing the gap from strategy to execution, and we’re excited to be sharing this in a two-day program in Cambridge, MA, on May 19th / 20th.

In addition to clarifying  the role of product owner and focusing on the challenges you face as a product owner, you will benefit by learning to:

  1. Conquer the chaos of backlog bloat and story hell
  2. Identify and vet new product opportunities in a way that invites, excites, and involves customers and internal stakeholders
  3. Convert strategy to reality by prioritizing the right strategic goals to define an agile product roadmap and manage a lean product backlog
  4. Convince internal stakeholders—from execs to engineers—why your investment choices are valuable and feasible
  5. Overcome requirements confusion and conflict by holistically exploring product options and making transparent decisions
  6. Lead teams and stakeholders toward shared product outcomes through dynamic collaboration

The Product Owner Survival Camp USA (POSC-USA) program provides you with essential skills to deliver high-value products. You will explore and practice powerful ways to align and collaborate to co-create valuable products that embrace the disciplines and philosophy of Agile/Lean product discovery and delivery. Evolve from surviving to thriving!

Join us in Cambridge, Massachusetts on May 19-20 for this unique two-day learning experience that combines the best features of a conference and a training class.

Registration is now open. For more information, visit

#productowners can help close the gap between strategy and execution
Categories: Blogs