Validation Sprints: A Challenge

Over the past few weeks, I've seen a number of posts about the uses of a Design Sprint. In short: when you're not sure what to build, prioritize the use of your team's time to gather requirements and build a wireframe version.

But how do you know if you've prioritized the team's time correctly - that you've built the right thing?  Again, easy answer: metrics.  Whether your team is organised around some combination of a formal practice (OKRs, KPIs, Pirate Metrics) or a hodgepodge dashboard, it's imperative that you measure the value of what you've done.  Velocity tells you how quickly your team is developing, not whether you're collectively delivering right thing.

Too often, this gets overlooked - once a feature is launched, it's on to the next one.  And the next one after that.  

Melissa Perri talks about this on the This is Product Management podcast, focusing on the Build Trap. TL;DR: there's no value to building something if you're not building the right thing.  (She's more articulate about it than that. Go and listen.)

We expect that the code deployed has been tested - and that it's built well enough to alert us if something has gone horribly wrong. The teams we work with should have faith that we're adhering to the same standard.

And most of the time, we do. Until things get too busy - whether it's useful things (validating requirements, securing resources, prioritizing, doing research, sitting in meetings, catching up with users), or reading posts from self-promoting colleagues...

So here's a challenge: Try a Validation Sprint.  Prioritize the time - for yourself or the whole team - to documenting the value of the work you've delivered. Then communicate what you've learned, be it positive or negative, and use it to improve your roadmap.