

Are your Product-Owners cross-functional enough?

In the last few weeks I’ve been using a new visualization that people find useful for understanding the relationship between the various Lean/Agile requirement containers. Some people call the full model a dinosaur. Others are reminded of the snake who ate an elephant from “The Little Prince”. (I’m sure there is a good connection to elephant carpaccio somewhere in here …)
The first step is to understand that for a new product there is a unique value proposition hypothesis. This is the area where your product/service will be unique.
The next step is creating a Minimum Viable Product (MVP) to test your hypothesis. This is focused on your unique value proposition but typically also provides a little bit of “Tablestakes” features just to make sure it is “Viable” as a product.
Your MVP is also an hypothesis. It might be good enough to find Product Market Fit or not. The case where each potential customer you engage tells you “This is great but in order for me to use it I need X” and X is different for each customer/user is shown below. This shows you are not in a Product Market Fit yet.
If on the other hand you are seeing more and more answers pointing to the SAME X then it makes sense to revise your Customer/Problem/Solution Hypothesis.
You essentially are executing a Pivot. You are building MVP2 focused on the new hypothesis based on recent Customer Development learning generated by the previous MVP.
Let’s say MVP2 is successful and you are seeing real traction of early adopters. You want to increase growth and are looking for deeper penetration of your early adopters as well as bringing on new clients some of them beyond the early adopters crowd. Based on feedback you’ve been collecting and your product management research you have a couple of areas that can potentially bring this growth. Some of them by the way extend your unique value proposition and some of them make your current product more robust.
In the case of areas with strong indication of value you might go straight for Minimally Marketable Features (MMF). Finding the minimum piece that can start bringing in growth. The aim of the MMF is to bring in value. It assumes high certainty that there is value in this area and that we know what the product needs to be to provide this value. The reason to break a big feature into smaller MMFs is mainly time to market and the ability to bring in value in many areas, always keeping your option to move to another area and provide value in it rather than focusing for too long on a single direction. An indication that you are working on MMFs is that when one is being shipped you feel comfortable working on the next MMF in that area. If on the other hand you want to wait and see if your first MMF sticks…
…then you are back in hypothesis land. But now your hypothesis is centered on a feature rather than your product. You have an area with high potential but also high uncertainty. The way to deal with it is to build a “pioneering” feature – the Minimum Viable Feature. The minimum feature that can still be viable for real use and learning from real customers.
If you learn that the MVF has hit gold you can develop more MMFs in that area to take advantage (if that makes sense). If not, you can pivot to another approach towards that feature area, or at some point look for alternative growth path. Essentially the MVF is a mini-me version of the MVP.
There you have it. The full model. Essentially my point is that you grow a product in uncertain markets by attempting various MVPs. Then once you achieve Product Market Fit you mix MMFs and MVFs depending on the level of Business/Requirements uncertainty in the areas you are focusing on.
While MVPs/MMFs/MVPs are atomic from a business perspective (you cannot deploy and learn from something smaller) they might be quite big from an implementation perspective.
The dinosaur carpaccio now comes in as slicing each of those pieces here to smaller slices aimed at reducing execution/technology risk. (typically these are called User Stories) Those smaller slices might have tangible business value but on the other hand some might not. It is more important for them to provide early implementation decision feedback along the way.
Feel free to use this model. Let me know what you think about it and how I can improve it!
One of the approaches I’ve been using lately with clients is starting with whole system Kanban, focusing on Discovery and Delivery, and then potentially zoom into Team Agile in some/all streams as the organization understands the concepts of Flow, Stop Starting Start Finishing, Inspect and Adapt etc. It IS typically necessary to go to smaller batches earlier on so I recommend setting up Lean/Agile Discovery processes that pull market/product demand and create Features, MMFs and Stories from it.
I want to quickly share a Kanban exercise I ran today in a workshop focused on this approach. The organization decided to indeed start with a Kanban system and
I won’t go into too many details, but if I see there is interest I might blog more about it, or write a chapter in the upcoming book.
The first exercise I ran today was Jesper Boeg’s HairDresser.dk Story Mapping Exercise. I followed his exercise with a discussion and short exercise for how the Story Map would translate into a Discovery/Delivery Kanban System, and how it might look like in several points along the development life cycle.
This setup the basic building blocks for creating the real kanban network of the organization.
We identified the product streams – 5 real Product streams driven by Product Management, with an additional stream covering R&D housekeeping, Research, Automation, etc.
We then split into small groups, each covering one of the streams – with the real PM of that stream as well as actual people that will probably be involved in working that stream day to day.
We then Visualized the work – at the level of Features currently in the various stages of the Stream – Backlog, Analysis, Implementation, Ready to be Released, etc.
Now it becomes interesting. Each Feature in a stream might require work from several different technological teams (4-5 of them). We gave a color to each technology team/stream and each group marked each Feature with the technology streams that were involved. We played with various expand/collapse patterns when trying to visualize the flow of these technology aspects of the Features, and discussed whether that visibility was required for a Product Stream interest level or not.
Then we took a step back, and went Small Batches. We took a couple of Features and sliced them to Minimally Marketable Features and then User Stories. Since we still have technology teams we still had to slice the stories to technological aspects, but at a much smaller batch size which will provide much faster/earlier integration/testing and faster cycle times. All of this still without going Feature Teams. The value of Flow/Pull without Iterations in this model is clear – there is no unnecessary wait between the time a Team finishes its “Team Story” until Integration can happen or Testing can pull.
We then visualized the Technological Team Stories and had another discussion about visualization patterns.
Next step was zooming into Technology Team Boards. It was simply a matter of collecting all the colored cards from the different Product Stream boards and representing them on a single Team Board for each Technology Stream. We are not even sure those Boards will be used at the team level up front. We might start with a Kanban system used by the people involved at the work management (PMs, R&D Managers/Leaders) to learn the ropes of the system and then extend its usage.
We also discussed priorities between Product Streams and the R&D internal streams. The understanding that allocating WIP to each stream and creating a Weighted-Fair-Queuing system based on that was very important. Senior managers in the room felt that this would make it much easier to meet the portfolio allocations the organization decided on. By default when work for a stream is finished it would mean pulling a new card from that stream. But there is still the flexibility to deal with struggling items by optimizing globally across Product Streams.
Another board level is the “Big Picture” board where the MMFs from each of the Product Stream boards will be represented.
The exercise brought to life the complexity of the organization’s network but highlighted how a Kanban system can simplify its operation as well as drive towards improvement. There were several A-Ha moments of understanding how Limited WIP would solve systemic problems currently haunting the organization.
It also highlighted how creating Feature Teams allocated to a Product Stream would make life easier from a coordination perspective. This gives the organization incentive to try some form of Feature Team approach when the time is right.
The fact that we exercised all this using real work of the organization, real teams, discussed real problems of starvation, one technology team being the bottleneck, how overall WIP limits might affect that, etc. was a great way to understand what an organization-wide Kanban system is all about.
I loved this exercise so much I’m thinking about creating a “sterile” version for advanced public product management / kanban workshops…
I wanted to share an exercise I created in a workshop last week
One of the topics we wanted to explore was the responsibilities/activities of Product Owners and the Agile Team and how do they relate.
The objective of the exercise was to understand the various activities and how they map in the continuum between PO and Team and across the product development life cycle.
The steps of the exercise are the following:
This exercise can of course be generalized to any interface between groups – Dev-Ops, Dev-Test, and outside of Product Development altogether… I’ll be glad to hear about interesting uses of the exercise.
A possible activity list (provided AS IS, no warranty attached… ;-):
What is the basic role of the Product Owner?
http://blog.crisp.se/2012/10/25/henrikkniberg/agile-product-ownership-in-a-nutshell (New)
User stories are the most common way to handle requirements in the agile world. One of the first things you’ll need to do as a product owner is familiarize yourself with them, and start to provide them to the delivery team.
Mike Cohn on Effective User Stories – http://www.mountaingoatsoftware.com/presentations/42-effective-user-stories-for-agile-requirements
User Stories Primer http://trailridgeconsulting.com/files/user-story-primer.pdf
Recommended Book – User Stories Applied by Mike Cohn http://www.mountaingoatsoftware.com/books/2
After you got the basics nailed down, go to some advanced techniques for managing and manipulating user stories:
Some process-related material:
Product owning also requires effective interaction with the agile process. Concepts like READY and Flow and how to effectively interact with teams are as important as the quality of the requirements themselves. Actually, in some cases, having the right process will help focus on doing the right things at the right time and solve some conflicts and problems product owners have.
Scaling the Product Owner
If you are working in a complex enterprise environment, you might need to look at some advanced materials regarding scaling. I would recommend reading and understanding some ideas, and also seeking professional help by those experienced in these environments.
http://www.infoq.com/presentations/lean-product-discovery
In general, I recommend to all Product Owners/Managers I’m talking to these days to look at “Lean Startup” to start thinking about the iterative learning associated with the Product Discovery process. Jeff Patton’s session above is a good introduction into this, but the whole body of work around “Lean Startups” is very interesting to Product people in general. You cannot afford to manage products these days and not be aware of it IMO.
I’m sure there are other great references out there, and I’d love to hear about them. But in the meantime, this is a reasonably comprehensive list, with the risk being a little too comprehensive. I would suggest you go top to bottom unless you have specific burning issues you need to skip to.
If you find this useful, tell your friends (and me!)
If you don’t, I’d appreciate hearing why!
Happy Reading!
Added the “Discovery” section on Feb 2012
Added Henrik’s brilliant short animated movie about Agile Product Ownership – October 2012