What you launch is what they get
“It’s in the backlog”; “that’s a fast-follow”; “It’s a v2"; “not part of our MVP”; “post-launch feature”
If you work in R&D at a consumer-web company, good chances you’ve either heard these sayings or used them yourself. Having led products at startups, as well as small and big consumer-web companies, I’m no different; I’ve been saying these myself.
Essentially, every new product goes through a process of feature scoping and prioritization and you will need to decide what makes the cut to the product that you launch.
D-day arrived. You’ve just launched your product. The team is already working on fast-follow features and V2 is just around the corner, right? Wrong!
Life is what happens when you are making other plans (John Lennon)
Usage data, customer feedback, critical bugs, higher priority projects – all these are bound to change your priorities and resource allocation. Then it’s adios backlog.
There’s nothing wrong with adapting and changing your product’s roadmap (product objectives shouldn’t change frequently, but the tactics of how to achieve them definitely can); in fact, it’s a big part of what makes consumer web so much fun.
However, using the fast-follow terminology and buying into its spirit has several negative implications:
Version scoping
On the one hand, planning for and believing that something will fast-follow, makes it easier to decide that you can actually live without it for the time being. On the other hand, working with the assumption that you will never get to the fast-follow stage forces you to think much harder about your scoping and prioritization. This doesn’t mean you should creep scope and constantly delay launches, to be on the safe side and try ensuring you have covered all possibilities. What it does mean is that you have to be far more focused and critical about what you really need in order to meet the objectives of the product you’re launching.
Managing expectations
You said it’s going to be a fast-follow, so when it doesn’t your credibility and your team, peers, managers, and customers’ trust in you are damaged. This is not to advocate that one has to cover their ass and use non-legally binding language. It simply suggests that you have to be honest and transparent. You should always be loyal to the objectives of your product, and clearly communicate the scope of new products that you’re working on and/or planning to launch. However, committing to a list of backlog items before you’ve even launched your V1, has high chances of disappointing both yourself and others.
Sticking to the plan, just because you said you would
In my view this is even worse than mismanaging expectations. If you commit to a list of fast-follows you may miss out much better opportunities, because you promised and ‘gave your word’. There is nothing sacred about a list of features in your backlog. The only thing that should matter is your customers and how you can best serve them using your talent and available resources.
I know what you’re all thinking at this stage. Hasn’t this guy heard of MVP (Minimum Viable Product)?
I have. What’s more, I’m a true believer in MVP. At the same time, I think too often it is being misinterpreted.
MVP doesn’t mean ”launch something and iterate from there”’. Before you come up with your MVP you need to be clear about the objective of the product you’re launching and ensure you understand your business environment. For example:
- If the objective of your product is to test a hypothesis, you should do whatever it takes to minimize effort and make sure you’re on the right track before throwing at it more resources.
- If you’re a startup, you are much more flexible in terms of the type of experiments that you can run comparing to an established brand with M’s of customers.
I therefore argue that you should always assume that what you’re launching is not the first version, but rather the only version of your product. This will lead to better planning, expectation management, and future flexibility.
Originally published at www.linkedin.com
