Recently I wanted to start with my team into a new topic and so we began a design sprint together: We unpacked problems and knowledge, sketched, prioritized, prototyped, got insights out of customer interviews and found some key use cases we wanted to realize in the first place. But, we also recognized, that our users have another 1000 and 1 very individual use cases in their mind. So to say it in Chris Anderson’s words: “A long tail of use cases” (Great book, by the way)!
What to do with such findings, when you want to live a MVP approach?
I decided to push my team to develop some kind of “tool box”, so that both of our Joe Doe users can realize the key use cases and our power users every other tiny use case which might come into their minds. I’ve had a clear conscience acting this way, because I respected the insights of the design sprint. Besides, many other competitors offer also this kind of tool box as well.
Sadly I couldn’t arouse enthusiasm in my team for this approach, never mind conviction. The guys asked me: “What are the exact requirements of this tool box?”. Otherwise they couldn’t develop it or might build a lot of features no customer would ever use! They also refused to evaluate any kind of framework/component until they know much, much more of this “mystique” tool box. Otherwise they might produce a lot of “waste”. Now long forgotten terms like “Requirements Engineering”, “Business analysis” or “Domain Model” began to circulate, which showed me, that something completely went wrong here.
Starting from scratch
After this “cat-and-mouse-game” went several days with hard and painful discussions, my team convinced me to start from scratch and start a “Requirements Engineering” phase. I wrote down every use case we had found in an odd Excel sheet (Yeah, much better digestible for all stakeholders then Jira), specified and prioritized it through allocated business value and in several workshops (Yeah, not as fancy as design sprints, but in such a phase a perfect format) we defined together our domain model.
One of the key moments was, that we found a common language through iterating through this Excel table and defined jointly a glossary! Yes, I know! This is a classic in project management. But this time I really underestimated the power, that lies in this artefact.
Conclusio
With a little bit of distance a tool box wish is fundamentally misleading in a costumer centric team, which follows the Lean Startup idea of a MVP! And with MVP I mean in our context building the most important feature(s) first and validate it against real customers and then iterate it (see Tim Herbig‘s correct definition of MVP)! Saying “tool box” tempts you as a PO staying in a comfort zone, because you stop doing the hard work of evaluating the nuances of each use case and prioritize them. So, my team has challenged me with justification!
So, if you stuck in an ongoing conflict with your team about the exact understanding of the problem space, than don’t be to snobbish and try out some classic methods of the good old project world! Design Thinking methods like design sprints are a modern and fantastic format for creating innovation, but must be enriched…
- with some kind of (discovery) workshops in front (because one day isn’t enough) or
- a glossary and
- joint domain modelling within,
when the problem space is hard to discover!
And, in such conflict times, listen carefully to your team and reflect critically yourself. Very often the most critical and experienced developers detect the ill thought out parts in your story!