There is no Step Two, or “What Comes After MVP?”

An incredible amount has been written about Agile and MVPs over the last 20 years, yet the majority focuses on the first step of a process, the output of which is stated to be a minimum viable product. This mismatch is likely a side effect of most literature being focused at organisations transitioning from out-dated practices and adopting something “new”[1]or desperately clinging on to the past in the case of SAFe – I’ll get to that article, eventually. There is much less writing dedicated on what to do when you’re up and running, with the general guidance being to reduce cycle times.

The conflation of process and product is confusing, often resulting with the view that if you simply “do agile” then the product will take care of itself. Often an MVP is the conclusion, with minimal discussion on what an MVP is outside of an expansion of the initialism. Let me give you an example.

About 5 years ago I was involved in a pitch to an academic publisher who wanted to completely rebuild their website. They made it clear in the tender that they did agile, and that they wanted to release the MVP alongside the celebration of the company’s birthday which kicked off on New Year’s Day.

My section in this pitch was to discuss this “MVP”, and I took the opportunity to lay some ground work.

  1. What does MVP mean to your business?
  2. What can you do without, or copy from the existing site (e.g. content)?
  3. Given your 1st January deadline, when do you actually expect to release the new site?
  4. What are you looking to achieve?

The answers were what you’d expect. MVP = Minimum Viable Product. Everything was to be new (code and content). To release a) when the fireworks went off at 00:00 on New Years Day, or b) over Christmas, as long as everything is finished. The aim of the project was to do the project, but any further “why” was elusive with no cohesive view shared, not even metrics.

Rather than doing agile, they had changed their terminology and kept everything else the same. MVP was the new word for a release, the solution was predefined (a complete lift-and-shift), and the scope was locked in. It’s waterfall, plain and simple.

In this instance there was no MVP, there was a project delivery. Even if delivery was managed through sprints, and some tweaks made based on stakeholder feedback, it still won’t have been an “MVP”.

Why? Because an MVP requires an hypothesis to test.

The purpose of an MVP is to find out if you’re right, as quickly and cheaply as possible. If there is no hypothesis, there is no product to access the minimum viability of.

I joined Safecall because they had a particular strategy they wanted to validate, and needed a Product Manager to shepherd it in[2]In the interest of full disclosure, this was started before I joined the business. I turned up towards the end of the initial delivery from an external supplier, but had been in post nearly 6 months … Continue reading. Would companies buy software from an expert provider with 20 years experience in whistleblowing services, but very little in building software?

Given the company’s lack of experience in the area, the last thing anyone would do is to write a cheque for several million quid to build a whistleblowing platform from scratch. As such, we used pre-existing products built to handle entities related to individuals within businesses to build our MVP. I also took the step early on to purposefully keep every page and interaction as simple as possible. Simple in this context means few screens, little conditional logic, and little fluff. For the first release, for the vast majority of Safecall clients, the platform operated as a secure means to receive and transfer confidential information, and little else.

We gathered feedback from existing clients who had been granted access to this new system, as well as through the sales process. The most common feedback was that “it’s a bit simple” – considering it isn’t “what are you doing, this is rubbish” I take this as a pretty big win. Over the last 2 years, the platform has become a core part of the service we provide and we have fleshed out some features, added some new ones based on new hypotheses, and reworked some areas where our previous assumptions were proven wrong, or we discovered unforeseen consequences. Ultimately, what we’ve proven is that, yes, companies will buy software from industry experts, and that it isn’t only “software companies” that can play this game.

An MVP is two things, it is a product, and a method of testing an hypothesis. In this sense MVPs are unlike any other part of the empirical, iterative nature of doing agile as it isn’t just a piece of research, it is also the thing you sell. In this sense, they are the most expensive way to ever prove whether you’re right or wrong.

The answer to “what comes after MVP?” is another hypothesis, one based off of the new data you have now been able to collect. This new hypothesis and new MVP can take many forms, from scamps to research aides to A/B tests, but your aim should always be to do just enough to clarify your assumptions, and test your hypothesis. Or, to put it another way:

Simplicity–the art of maximizing the amount of work not done–is essential.

https://agilemanifesto.org/principles.html


And then you do it again.

Notes

Notes
1 or desperately clinging on to the past in the case of SAFe – I’ll get to that article, eventually
2 In the interest of full disclosure, this was started before I joined the business. I turned up towards the end of the initial delivery from an external supplier, but had been in post nearly 6 months by the time we’d made our first release in March 2019

Kill your product

Last time, I ended by summarising that to progress you need to quickly iterate, and threw in a link to the wiki page on Fail Fast. A couple of posts ago I was waxing lyrical about bass players, and ended saying “Print that 7″, and move on.“. The theme here is obvious:

  • Do something
  • Pay attention to what happens
  • Use your new knowledge to do the next thing

When speaking about doing agile, especially when migrating away from outdated methodologies, people often focus on the individual side of it, the most obvious being differences between Command-and-Control Project Management versus Servant-Leader facilitators.[1] Scrum Masters, Agile Coaches, etc

But from a Product perspective, hubris is often king. We all know Product people who think they are the second coming, are absolutely indispensable, and have some sort of perfectly unique take.[2]Ed: You really want to open that door, huh? When you consider that an agile approach to Product requires you to run experiments and accept that you’ll make mistakes in order to learn, this is in direct conflict with corporate cultures which reward (perceived) perfectionism by way of arrogance, bravado, and the safe space afforded by feature-and-revenue led project plans. This can lead to people who have been moved in to Product positions[3]Often from previous “decision making” roles, such as a member of SLT, Programme Managers, Project Sponsors, etc as part of a transformation piece deciding that while everything else is changing, they don’t need to.[4]I’ll cover this in greater depth in a future post, for now let’s put a pin in this and move on, but do keep it in mind.

The other part is the wider side – what are others doing?

If you consider a market of similar software products, there will be multiple companies and competitors, each making changes and learning from successes and failures. While no one has perfect knowledge, other people making mistakes for you is extremely cost-effective. And much like how you will look to take advantage of your competitions’ weaknesses, they will do the same, as their aim is to take money out of your pocket and put it in theirs.

If you’re able to learn from the mistakes of others, as well as your own, and act on them quickly, then you’ll have a better chance at staying ahead.

To fully learn from these collective mistakes, Product needs to do something particularly painful, they need to go out with the intention of killing their product. They must view their creation through the lens of a competitor, and rather than make excuses, they must pick it apart, highlight its flaws, and ruthlessly remove them.

You need to get over your own bullshit, because if you don’t kill your product, someone will gladly do it for you.

Notes

Notes
1 Scrum Masters, Agile Coaches, etc
2 Ed: You really want to open that door, huh?
3 Often from previous “decision making” roles, such as a member of SLT, Programme Managers, Project Sponsors, etc
4 I’ll cover this in greater depth in a future post, for now let’s put a pin in this and move on, but do keep it in mind.

Time to live

Businesses who conduct any form of software development are increasingly “doing agile“. Typically this means they’ve replaced traditional waterfall project management within their “IT department” to probably Scrum or SAFe[1]For the sake of brevity I’m skipping over why SAFe is a step backwards and only entrenches problems. That’ll need a post all to itself., within smaller and larger orgs respectively.

A few people will go on a course, and on return set up a Jira / VSTS board, book a morning meeting titled “Stand Up”, and the release schedule is changed from Quarterly to Fortnightly overnight. On the surface, this is a step in the right direction[2]It isn’t..

If agility is a concept restricted to just your technical teams, and not your business as a whole, then you’re not actually “doing agile”.

A conversation I routinely have with friends, (ex)colleagues, and the like, is about how tired they are because of the level of extra effort required to affect change within their organisations. This is across all shapes and sizes, big/small, paid/voluntary, public/private.

The conversation will eventually meander through two topics:

  • How long it takes to make a change – start to finish? From concept, to delivery, not just development.
  • How much resistance occurs along the way? Do they feel that it is their own personal determination that makes change happen, instead of something which is embraced?

Complaining about work and feeling helpless isn’t new, and given that it is the plot for three of the biggest films of 1999 I’m not pretending like this is some sort of revelation. However, the frequency of answers[3]My sample is self-selecting because this conversation doesn’t come up in relation to organisations where the answers are “no time at all”, and “very little” being “a long time, could easily be a year or more“, and, “oh, so so much, I’ve given up more times than I’ve failed, let alone succeeded” coupled with the clear frustration expressed is something which leads me to believe that while this isn’t by any means rare, or novel, it’s actually an accepted, expected and purposefully constructed scenario by the organisation itself.

This is often done under the presumption that enough approvals and controls will ensure certainty of two things:

  1. Nothing bad will happen
  2. Only good things will happen

A fundamental aspect of doing agile is embracing uncertainty. To embrace uncertainty you need to be able to make changes quickly, and learn from them.

To make changes quickly, individuals need to be empowered with authority and responsibility delegated. They must be able to make meaningful change without arbitrary approvals and sign off. Equally, they must be responsible for the impact of those changes. That responsibility must be against quantitative targets, not subjective opinions. If they fail, they fail – now learn from it, and try again.

If your organisation can only do things quickly when the house is on fire, and you use executive authority to bypass red tape, then you have systemic issues which need to be addressed. Because if they aren’t, then you better be absolutely right in every decision you make, otherwise you’ll lose to a competitor who can move faster than you and found out the mistake long ago.

It can’t be left up to the determination of individuals.

Notes

Notes
1 For the sake of brevity I’m skipping over why SAFe is a step backwards and only entrenches problems. That’ll need a post all to itself.
2 It isn’t.
3 My sample is self-selecting because this conversation doesn’t come up in relation to organisations where the answers are “no time at all”, and “very little”

JFDI

Sid Vicious couldn’t play bass, and only recorded parts of a single bass track on Never Mind the Bollocks.

Sandy Miranda can play bass, and in 2006 released a studio album, nine 7″s, three cassettes, and a CD.

Omar Rodríguez-López got bored of playing bass at 12, started playing everything you can imagine, and has written, released, and/or produced more music than I can possibly imagine.

Actually, that award goes to Buckethead.

Even so, the Sex Pistols are generally considered as one of the most influential British bands. Causing the formation of The Damned and The Clash (Paul Simonon also couldn’t play bass, at first) with both bands playing their first gigs as openers for the Sex Pistols. Then, as the apocryphal story goes, a gig at Manchester’s Free Trade Hall on 4th June 1976 had attendees who would end up founding Joy Division, The Fall, and The Smiths.

How does a band with a bassist who can’t play bass have an influence like that?

Or, a better question – how do have the confidence to join, or even start, a band when you can’t play an instrument?

Sid’s snarled expression helps, you just fucking do it. Because who’s stopping you?

A more restrained statement may be that everyone must start somewhere. Edin Blyton didn’t wake up one day and decide that she was going to write 762 (slightly problematic) books. $FamousFootballer wasn’t born being good at SportsBall. The chef’s on in the Michelin Guide didn’t go from microwave mini-pizzas to whatever it is Heston is doing right now I mean come on.

You may have a vague notion or hope that, some day, you’ll fill a room with your creations, but thinking that success is only that – and nothing else will do – will destroy you.

It is a rather trite statement, but you must see how perfect is the enemy of good, and that it’s actually much more important that you do the thing, rather than obsess over it.

That’s how you learnt every skill you have, and that’s how you’ll continue to improve. Oh, and you’re probably not destined for greatness, and that’s ok! Literally no one is! Again, something doesn’t have to be perfect for it to be worthwhile, or the right thing for you to do.

Even Sid Vicious got better overtime, and by the time he died was…alright? I guess. I mean, he wasn’t John Entwistle – but who is?

Don’t let perfection stop you. Don’t spend more energy talking yourself out of doing something than it would take to just do it.

Print that 7″, and move on.

Release, repeat.