This is an approach I developed a couple of years ago whilst working with a team in a difficult (but quite common) situation at my previous company.
Bizarrely, about a week after I started drafting this article (a long while ago now), another blogger independently described an almost identical tool and approach, I just wish I could find it.
The Product Manager for the team I was supporting was responsible for a small portfolio of products of varying age and quality and like many Product Managers I’ve met, he had insufficient budget, time or delivery capacity for “everything”.
One product in particular was causing pain. Commitments had already been made to at least one large customer that a “radically overhauled” version of the product would be delivered to address all their reported complaints.
(You know – the kind of commitment made when you’re on a customer site and they’re tearing you a new one over a multitude of frustrations and you just want to make them happy, right?)
This commitment had been made on the spot prior to any investigation and without consulting the development team.
Did I mention how much I now enjoy working for a company that only sells software that already actually exists?
This overhaul wasn’t just being developed for that one customer. They wanted to re-launch the product as an advanced graphical web-client with full multi-user query/read/write/print features. (The original was a read-only system)
When the team started to explore the “product”, they realized just how customized the customer’s version was and how unloved, limited and just plain sick the original was.
- The UI sucked
- The underlying code was the result of years of consulting engagements strapped together
- Consultants has to wire the internals together to make it a running product (Out-of-the-box it didn’t work)
It was basically a collection of disparate tools in a very jumbled toolbox.
Despite all of its ugliness, many customers were actually using it. It was typically thrown in free with most enterprise licenses and was far easier and cheaper to roll out to the majority of users than the seriously advanced thick-client CAD-like system.
The team had their work cut out for them…
All they had to start from was the usual laundry list of features – 1-liners. Fortunately this was enough to be clear already that they were never going to deliver “everything” (or possibly anything) on time.
Fortunately their Product Manager was a great guy. Masses of domain and customer knowledge, supportive, collaborative, made time to be available regularly despite being on the far side of the world and experienced enough with software development to know when to listen to his technical team.
The team highlighted the impending scope & schedule disaster as soon as it reached their shores and within a week the Product Manager was in the UK ready to hit the reset button.
We needed to re-frame the project, determine what scope could be cut or postponed, what could be delivered sooner, what was a priority and how the team would approach delivery.
We arranged 3 days of workshops with the product manager and full development team in the room together.
Before we dived into details, we worked with the product manager to give us the real story on why the product existed from our business perspective:
- What revenue did it provide?
- How else did it support our sales?
- What was the longer term direction for the product?
This was restricted to 1 sticky per question.
We then captured (on 2 stickies) what the users normally did with it – what were the most commonly used functions and what was the frequency and duration of these activities?
To start things out with the best possible foundation, we spent the first morning on “Envisioning” (or perhaps “Re-Visioning”).
I’m not convinced the Product Manager was particularly sold on the value of the session but he was willing to play ball – he trusted the team and I to do the right thing. (and after all this was just 2 hours of warming up for 3 days of workshops).
As we started it became apparent from team conversations that they were struggling to establish exactly what the product they were working on was really expected to do, why and who for. (pretty fundamental stuff)
I led the team through a series of facilitated discussions around 6 areas of the project/product. The order we approached these and the constraints used for documenting them were a critical part of the process. We constrained the documentation to the smallest, simplest thing that could possibly work. One sticky per conversation theme.
- Needs – What top priority business needs is the product/process addressing?
- Wants – What do the end users want from the product/process , what specific tasks are they trying to achieve?
- Business Process – What business process are we aiming to model, support or improve?
- Scope – What’s the explicit planned scope (features & fixes) for this release? (limiting scope to a single sticky is a great way of starting out small!)
- Immediate Goals – What is the top priority single goal of this particular project/release?
- First User – Who will be the first actual consumer of what we’re delivering and when do they need it?
We knew the product manager already had an idea of what scope he wanted and that we were going to need some kind of polite reset conversation.
Our approach was to collaboratively define what the “minimum marketable feature set” (MMF)** for this release would be.
**At this company, MMF was loosely defined as “the bare minimum set of functionality that would be added/improved in order to deliver incremental customer value and be worth announcing to the market.”
Through scope exploration, we established the team needed to deliver a lot to make the product viable. We were however able to trim a number of very high complexity/risk items in order to bring things in sooner. Better still we’d had a powerful scoping conversation with the product manager to set clear expectations on what would be highly unlikely to be delivered and had sequentially prioritized every other feature in his original release wish list.
Putting each item on a sticky, and having an explicit MMF marker was a great way of visually defining the backlog. (This also kept the number of items in the backlog small enough to summarise quickly)
The final piece of the puzzle…
Having defined context, scope and vision for the release, we defined what “acceptance” of a new release would entail for the end user. The power of this was that we could correlate current and later scoping conversations around the fundamental user acceptance expectations without our Product Manager getting emotionally attached to the scope we’d originally talked through. Once again, we constrained the acceptance to keep things small and simple. (one sticky was plenty) .
After this initial few hours, the team spend the remaining 2 and a half days working hard with the product manager to flesh out all the top priority features/epics in sufficient detail that they could start de-risking and developing by the end of the week. They didn’t need my help for those bits 🙂
Note, the quality of writing on this article may not be up to my usual standards. This has been blocking my backlog for quite some time. I needed to get the story written from my rather hazy memory and move on more rapidly than normal. I hope however that it’s still valuable.