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.
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
The “Line of Chaos” is a concept that good product managers will not just understand, but will embrace with vigor.
First, let’s start with what it is. It is an imaginary line that serves to illustrate the interface between business and technology. Why does that interface matter? It matters because business people and engineers are fundamentally different.
Recall the post by Paul Graham about Makers vs. Managers. Business people, especially sales people, thrive on selling, meetings, making clients happy, reacting to the client or market, the (not so) occasional fire-drill, and often just raw activity. They are interrupt-driven. How many times have you heard someone say, “I’m so busy! Look at all the meetings I have on my calendar.” They frequently switch context. They lie in the now. It is often fluid, reactive, and, well, chaotic.
Engineers (I’d include designers in this too) thrive on long blocks of deep thinking to solve problems. Output should be the measure of productivity for engineers, not the activity or the lines of code. In fact, time to think, not code, may result in the best output (a scalable design or elegant feature, for instance).
None of this is controversial. The thing that isn’t mentioned in the PG article is how those two different worlds can work together to great effect. This is where product managers step in. They are responsible for defending the engineers from the chaos. In some ways, they are responsible for saving the business people from their own chaos (even if they might not know it at the time). PMs are the keepers of the Line. Good PMs will fight to the death to ensure that the Line does not penetrate the engineering team.
The keeping of the Line of Chaos takes many forms for a PM. Prioritization. Stakeholder management. Feature benefit analysis. MVPs. Product strategy. At the end of the day, these and other common principles of product management are just tools to fight back the Line of Chaos.
This is not to say that the Chaos does not serve a purpose. It does. Great ideas often emerge from the chaos. But, even then, the idea is going to need some help to get presented to the engineers in a way that puts them in a position to be successful.
Great product managers are hard to find. There aren’t a lot of people who can both operate in the chaos, while simultaneously fighting it.