Series 1: Lessons on Agile - Part 1: Build half of what you think you need

Putting the 'minimum' in MVP

This post was inspired by Scott Belsky’s interview on Lenny's Podcast - you can watch/listen here, it’s a gem!

The MVP - a term new for some, but for my generation of PMs this has become the modus operandi.

I have spent much of my career building MVPs and working in the early stages of products, and upon honest reflection, did it wrong most of the every time.

For my first proper newsletter post I thought I’d jump right into this important topic, explain where I (and I suspect many others) have gone wrong in the past, and offer a suggestion for how you can remedy the common pitfalls.

---

So - let’s start with a story: you’re an ambitious PM trying to make an impact. You've come out the other side of an intense Discovery, which ended with a hard-fought prioritisation exercise with your key stakeholders.

Maybe you did some dot-voting, MSCW’ing, or using an impact/effort matrix to get there, but the key thing here is that you think you have identified the ‘must have’, minimum set of functionality for the new feature/product. With the MVP scope clear, you brush the dirt off your shoulders, pat yourself on the back for getting through that battle, and begin writing that PRD. Phew, the hard part is over…

…But before before you know it, work has started and things are beginning to slip! 😱

Tickets are more complex than expected, scope creep begins as requirements were missed, new data causes a pivot, the design had an error, and you maybe even faced a late-stage HiPPO attack (where, seemingly out of nowhere, a senior stakeholder throws out some unseen ‘showstopper’ requirement you need to address).

Perhaps you got lucky and caught this all early, but more often than not, this seems to happen at the worst time, right when you think you were about to cross the finish line. Regardless, the end-results look the same: stress, missed deadlines, last-minute scope-cutting, and disappointment. Inevitably, you look at your finished ‘MVP’ and realise there were a bunch of things that maybe weren’t so ‘minimum’ after all…

---

Sounds familiar? I thought so!

I really couldn’t work out why it happened for me, time and time again, no matter how much time we spent in Discovery, delivery planning, requirement grooming sessions or running dev ‘spikes’.

That was until I heard these statements from two brilliant product leaders:

“Prioritisation must hurt” - Fabrice des Mazery

“Only build half the features that you want” - Scott Belsky

These prompted a eureka moment for me, and a realisation that more battle-scarred PMs know all too well - you should assume that those ‘slips’ will always happen. With that as a given, you must be ruthless when setting the bar for your MVP, and give yourself and your team the contingency space and leeway to allow for them.

Understanding this, from now on I will try to reframe the prioritisation process as follows...

Instead of stopping once you’ve decided the ‘must-have’s’ - you enter a final phase: deciding which half of those features will make the MVP. This may feel like a bit of a sledgehammer approach, but it’s a sure-fire way to laser-focus in on what really matters. You must not compromise on the 50/50 split - S.O.B .

There are many ways to approach this, and I’ll do a post in the future documenting how I do it when the time comes, but some practical tips I’m thinking for now are:

1. Grab your stakeholders, a whiteboard, draw a line across the middle, and write all the shortlisted features on individual sticky notes. The aim of the game here is to get half the stickies on each side of the line. This might take some iteration, and expect it to be hard! I think a virtual whiteboard could even be better for this, as you can connect inter-dependent features with a line to ensure you account for dependencies. I’ll definitely dry-run it myself first as a thought exercise to see whether I’d be happy with my own outcomes here.

2. Go back to your problem statement(s), personas, JTBD, data etc - any of these kind of artefacts that reflect some sort of ‘truth’ about the problems you’re trying to solve for the user - unless a feature directly relates to any of the problems you’re trying to solve, this is evidence to move it below the line immediately

3. Sensitive communication will be key. This isn’t about disappointing stakeholders early, and it doesn’t mean the MVP will be bad either. Leverage your organisation’s product leaders to help you with framing this conversation/exercise appropriately - pissing stakeholders off at this stage in the game definitely won’t win you any prizes!

---

Beyond the direct benefit of hopefully delivering your MVP on time, with the right set of features, there are a number of other benefits to this approach:

• A reduced feature-set means you are likely more focused on testing your key hypotheses about what you’re building

• It also means a reduced feeling of the ‘sunk cost’, and a less burdensome pivot technically if this is required

• Narrower feature-set = more focus on each feature, so you can catch snags earlier

• Empathy from stakeholders: maybe, just maybe, they might be less tempted to throw new requirements your way if they were part of the painful prioritisation process in the first place

Ben

---

Did this resonate with you? Have you implemented any similar approaches in your organisation? Did they work? Let me know in the comments.

I’ll be back in ~2 weeks with part 2 in the ‘Lessons on Agile’ series: it ain't easy being iterative