Momentum after the MVP can be a hard thing to obtain.  All products start life with the best intentions, but due to many reasons there is an ever-expanding corner of the internet turning into an elephants graveyard of betas, MVP’s and failed experiments.

A lot of these unloved dreams didn’t start their lives outdated, out of touch, or unsalvageable. In fact, a lot of them would have been classed as successes when they were christened “live” but they succumbed to an epidemic that has plagued the heart of product teams for years…. “Phase 2”

You know about “phase 2”, it’s that thing we never got round to building, that thing that if we had all the time in the world we would go “get”. But due to priorities and changing of the tides it never seems to happen. The basis of an MVP is “we do the basic stuff now (to a good standard), learn from it, then improve the product” which the digital world is buying into in spades. But it seems the last 4 words go in one ear and out the other.

Lets face it, sometimes it’s not sexy to come back to a product. In an environment where we may be judged on the volume of output, teams can be forgiven for wanting to focus efforts on something else once an MVP has made it to market. But one mans MVP becomes another mans failure if the right action isn’t taken after that maiden voyage. I have taken products to market that have had great product lifecycles and I am not ashamed to say I have some horrid elephants out there (for the love of god I hope Find Me Vintage has been taken down!), but there are themes that seem to work well for me once that product is out there to keep momentum going:

Say what success looks like
Before you go live with your MVP set out a goalpost of success, say what it needs to be achieving at this stage to validate the time spent. That doesn’t mean if the product doesn’t meet expectation you should kill it, but if you do not have an agreed measure of what success looks like then how can you validate if further iteration is something to pursue?!?

Track, track, and track
Make sure you have the correct tracking in place, there is no point in setting out a goal for your product unless you can actually measure if it is successful.

Have a backlog
I like to take anything that hasn’t been completed from the previous round U.A.T and stick it in a backlog, a living backlog, not a spreadsheet only you have access to. Because you never know when there is a rainy day and you have some idle time in your team to get some stuff done.

Constantly challenge your thinking and the product
Be hyper critical. I love this ideology I first read about in decisive by Chip Heath. The book is about how to be more decisive in work and life, but there is a chapter on change and improvement and there is a great case study where the mantra of a management team was “If I was my successor, what would I do?”.  I love that idea. I like to think of the next “me” coming into my job, sitting at my desk, looking at what I have done so far and say “right, here is where he didn’t do so hot, I am going to go after x, y, z”.

Take that approach with your product, look at where the weaknesses are and make them big targets hanging on your team, and challenge yourself and others to eliminate them with the eagerness and thirst for blood like someone coming in on day one.

But sometimes we are blind to our weak spots: just ask the development team who created windows vista, sometimes you need to follow a more scientific approach to find your weaknesses. That leads me into…

Workshop your pain points
Sometimes its quite easy to see your weak points, usually they are pain points with your product, or time spent on something that isn’t meaningful. But either way, you should validate these with actual users. I have a post about basic expectations where I look at the simple ideology that you will never make something truly innovative unless you meet basic expectations everywhere. That point is just as relevant here. Map out the whole user journey and find out what your users like and don’t like and remove things that make your experience cruddy.
Look at this case study for my DLC, a debt collection app taking a generally horrible experience and making it bearable, so bearable that the app won awards. I know, imagine an app based on one of the most horrible times a person can go through winning awards for user experience!
That is because they looked at each step in the user journey and actually found where the pain points were and turned them into delighters for the user (apart from the obvious one of owing a load of money to people who can take away your home).

Talk is good, but commitment is better
Actually put time in to review where your product is, how well a feature is going and where it should be looking to go next. Say to your boss, “I actually want us to lock some time in to improve our product, I may not know what that is yet but it’s important we make time for it”. There is the other side of the coin that is when something doesn’t work, actually commit to allowing it to fail fast. That means killing it when you know it isn’t working. The last thing you want is something that isn’t actually bringing any benefit to your users floating around for someone to find, have a terrible first impression and never trust your brand again.