Create a Real MVP

I hate weasel words. So many words get bastardized and misrepresented, especially in business, but it happens in politics, science, and other fields too. They become trendy. They become buzzwords. Companies feel they need to use these words or else they look like dummies. Guess what, most of the time when you use the terms incorrectly, you look like a complete dumbass.

Some of my favorites from the software / startup world…

“Platform” – your website is not a platform. It’s a website. Or maybe it’s an app. Unless other people can independently build whatever they want on top of your software, you are NOT a platform. Stop it.

“Disruptive” – everyone thinks they are disrupting things nowadays. Really? Giving people a new filter to put over their picture of dinner is not fucking disruptive. Poor Clay Christensen. I’m sure he had the best of intentions, but the jackals hijacked his concept. Now it’s meaningless.

The one I’m going to deep dive on today is “MVP.”

Thanks to Eric Ries and Steve Blank, everyone’s talking about MVP nowadays. However, in my observations, people are using it as an excuse to put crappy shit out there. MVP doesn’t mean it’s OK to be crappy. Your product still needs to be good. Most of all, it still needs to be valuable and meet whatever goal your user is trying to achieve. Otherwise, all you have done is spent money to “test” and make someone’s day worse. They’ll never get that time back from trying your sloppy product. Don’t do that to them. There is enough anguish in the world.

A better term would have been Minimal VALUABLE Product. I think that re-frames the context in the right way. What is the simplest, most straightforward way to create value for your user? Reframing the question in that way puts it all in perspective.

The team at Spotify has nailed this. Below is from a presentation given by XX that illustrates what an MVP really is.

spotify-mvp — Image credit: blog.crisp.se

It’s simple, but powerful. If your user’s goal is to go somewhere more quickly, you should maniacally focus on that. Even if you are the next Steve Jobs and can dream up the most badass sports car to serve that need, you have to start somewhere. You’re a lunatic if you think it’s best to spend 5 years building the dream of that sports car. Then you’re in waterfall hell with no shot at actually delivering the car on time, let alone managing the risk that what you dreamt up might not be what your user in 5 years may want.

Instead focus on the goal. Get somewhere more quickly. How would you do that. You wouldn’t start by giving them a tire. They can’t do anything with a tire, even if it might be a part of the end product. Reframing leads you to think about the most straightforward way to get your user somewhere more quickly. So you build them a simple skateboard.

BOOM. You deliver value immediately and your user is delighted. They can get somewhere faster. Then you talk to the user and ask him what’s challenging him now. Oh, you hare a hard time balancing? Why don’t we add a little steering column. More value. Build, Test, Gather Feedback, Hypothesize, Repeat.

In five years you end up with a sports car. But now you have a user who is a huge advocate because they’ve been benefitting from your awesomeness for five whole years. Isn’t that awesome? I think so.

So, take off your black turtleneck and stop building sports cars. Reframe your problem around your user’s goals. Then think really hard about how you can meet that goal in the simplest, most straightforward way.

Other great articles on this topic can be found here, here and here

Product Owner Skills

We are now about five months into our transition to Scrum. Embarking on the experience as a Product Owner has been awesome. I recently came across a useful graphic that outlines the skills (and there are many) that make a good product owner.

Credit to http://williamgill.de/2012/10/01/the-product-owner-the-poster/

This is a good summary. I would add Authority to the chart (but that messes up the layout of the poster, so I’m sure the creator had to make some hard decisions). Authority is a more nuanced form of leadership, in my opinion, but it is important to call it out on its own. Authority comes from your domain expertise, and the way you carry yourself with the dev team and the rest of the organization. You earn this, you don’t just ‘have it.’ It’s a hard thing to master, but it is instrumental to your success as a PO.

Pivoter Beware

Entrepreneurs seem to have the stubbornness or self-confidence to fail, dust themselves off and try again. The idea that a company can and should fail, but fail rapidly and re-adjust their trajectory as needed, commonly known as “pivoting” is a further manifestation of this entrepreneurial spirit. It is a founder-friendly concept that is key to the lean startup methodology. It is in the best interest of all stakeholders to allow and sometimes encourage pivoting to occur. If a startup can recognize early on that they need to re-adjust, they have a much better shot of recovering from initial setbacks, but this approach does come with some risks.

The term “pivot” seems to get thrown around with increasing regularity during discussions of lean startups. “How did they pivot,” “Why did they pivot,” “How many times did they pivot,” “What is a different pivot that they could have executed on,” and the list goes on. In some sense, it seems like there is a notion within the ecosystem that pivoting is a requirement to be a lean startup.

However, I feel that this misconception is a dangerous one. While pivoting may be appropriate in some situations, it is certainly better to avoid it, if at all possible. Relying on the ability to pivot, often at the expense of developing a compelling initial product vision does not come without consequences.

Continue reading “Pivoter Beware” →