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 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 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:
- Map all the activities related to the life cycle – typically this will be the lifecycle of a Feature. I came with a set of predefined steps but I think it can be useful to let the participants come up with the activities as a digesting activity.
- Where does each activity lie in the lifecycle? Use horizontal team estimation game – this means coming up with a continuum of activities where starting point is to the left side, ending point is to the right side (to be compatible with a typical Kanban Story Board)
- divide the time continuum to a couple of key phases (this can be used to be a starting point for a Kanban board btw, or you can use the existing kanban board the team uses if applicable )
- Which activity is associated with Product, Which with R&D? Use vertical team estimation game to drive a consensus among the team. The meaning of vertical is that you don’t touch the left-right placement, just the top-bottom. Top should be solely Product, Bottom solely R&D. Identify a middle area where work is done in collaboration. Even within that area it makes sense to discuss who is “leading” the activity.
- Debrief – Have a discussion about what this means, what are the surprises, does this make sense, what you would like to experiment with.
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… ;-):
- Decide how much to pull into sprint
- Estimate effort for stories
- Write ATDD Scenarios
- Estimate effort for MMFs
- Write confirmation DoD for Stories
- Break MMF to Stories
- Decide which Stories should stay in the MMF
- Approve Test Plan for Story
- Approve Test Plan for MMF
- Decide how much to pull into Release
- Decide which MMFs get priority
- Commit to delivery date of an MMF
- Decide delivery date of a Release
- Prioritize MMFs
- Break Feature to MMFs
- Guide UX Design
- Break PRD to Features
- Accept/Reject Stories
What is the basic role of the Product Owner?
Starting with user stories:
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
User Stories Advanced Techniques
After you got the basics nailed down, go to some advanced techniques for managing and manipulating user stories:
Some material on Agile Release Planning:
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.
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!
Added the “Discovery” section on Feb 2012
Added Henrik’s brilliant short animated movie about Agile Product Ownership – October 2012