Then on to traction, scale, and ultimately growth.
One of the most difficult decisions a leadership team needs to make is what to do with the resources that built the product now that the product is built.
Do you focus those resources on strengthening the infrastructure that sells and supports the product? Or do you push them to keep building a better product that brings in more customers and keeps those customers around longer?
Obviously, the answer is both. So here’s how to prioritise.
Chicken (infrastructure) and egg (feature set)
An MVP will, by its own nature, have a lot of gaps and flaws. If your team has done that first phase right, those gaps and flaws will mostly impact the infrastructure side, with very little friction for the customer.
In other words, the product should work great, maybe even perfectly, as far as the customer is concerned. You got that product to market quickly by cutting corners in the infrastructure that produces, sells, and maintains the product — processes like transaction, fullfillment, and support that are now mostly manual and probably not scalable.
Now you’ve got time to go back and harden those processes.
However, the product you’ve released, while close to perfect in the customer’s eyes, is only enough of a product to prove that the product deserves to exist, not to scale, not to completely solve the problem you’re trying to solve, not to produce a big windfall to your bottom line.
But the more features you add, the more weight you put on the infrastructure, which could cause the whole machine to collapse.
The case for spending resources on internal infrastructure
When I launch a product to market, I do so with “starter” versions of sales, transaction, fullfillment, and support. I do this because spending time and money perfecting these processes this early will cause issues:
- It slows time-to-market while the infrastructure gets built to accommodate a position I won’t be in for several months, if not years.
- It adds unnecessary and sometimes wasted time spent working to support edge cases that may never happen.
- It’s expensive to maintain, maybe only fractionally, but enough to impact the bottom line this early in the product’s life.
- It adds friction. At this point I should be selling and supporting my customers, not all customers.
Instead, what I’ll do is build out just enough infrastructure to support the customers I have. This way, I’m not making guesses about what the next 10 or 100 or 1000 customers will need. Then, I keep improving the infrastructure reactively, using what I’m learning, and proactively, with some good data behind more educated guesses.
Here’s a simple example. If I start an email list, I’m not going to buy the enterprise version of MailChimp that includes 200,000 subscribers and all the bells and whistles. I’m going to start with the free version and let my subscribers tell me which bells and whistles they need.
The case for spending resources on external features
Just like a rocket, your product launch provides only so much velocity and fuel, and then you’re left floating until you fire booster rockets.
These boosters could be new and better features, marketing campaigns and programs, or demos, trials, and experiments – all of which serve the purpose of bringing more customers to your company and keeping them as customers longer.
Again, when I launch a product to market, I make sure it does the core thing well. That core may include, say, five features, leaving probably another 100 features on the roadmap. I didn’t launch with those 100 features on Day One because:
- The business case for any of those features wasn’t complete.
- Feature overload will actually drive potential customers away as they struggle to understand this new solution.
- If the product can’t succeed with the core package, chances are it will never succeed. I need to know this immediately.
Here’s a recent example of my own. My Teaching Startup solution started as an affordable paid newsletter that offers answers to entrepreneur’s questions about building and growing their business.
The thesis for the solution is: Can I deliver 80% of the value of a traditional advisor for a fraction of the cost? If that thesis, executed in the form of the newsletter, didn’t succeed, the 100 other features I had on the roadmap, most of them around a costly-to-build app, would also not succeed.
All your goals will blend at the point of customer value
So that’s your decision matrix, and these are the goals you’re chasing:
- Understanding the customer journey to get them what they need more quickly (internal).
- Better customer retention through more active and more helpful support (internal).
- More customer engagement and usage through more and better features (external).
- Speedier time-to-market of new features that continue to expose and improve the solution (external).
- A feature-rich product that expands the volume of potential customers to improve the top line (external).
- Automation, repeatability, and scalability in the infrastructure to improve the bottom line (internal).
All of these goals, regardless of whether they’re internal or external, are rooted in one common metric.
Customer value.
When customers see potential value quicker, they buy quicker. When they experience value more frequently, they stay longer. When new features add more value, they pay more. When they understand value better, they’re less costly to support.
All roads point to value. Here’s how you strategise your needs and prioritise internal vs. external projects.
First: Patch ALL critical needs and outsized risks
Let’s talk about hot-fixes first. There’s a line at which all priority lists go out the window and everyone works on a fix for a problem that’s potentially customer or company threatening.
You’ll need to draw this line first, because after launch, EVERYTHING is an emergency. Features will break, customers will get irritated, support calls will be dropped, transactions will fail, and on and on. Every single one of these issues has a chance to become the company’s top priority, and not every single one of them can.
This leads to the philosophy behind your prioritisation strategy. You have to be comfortable with making customers unhappy, with losing customers, with losing revenue, with generally not doing your best in every area, all the time.
Don’t get me wrong. You have to strive to make every customer maximum happy all the time, whether that’s with your product or the machine that sells, delivers, and supports it. But when every priority is the top priority, it means none of them are.
Internal prioritisation: Quieting the noise machine
Once you define what makes an issue hot-fix critical , the next step is to prioritise all the other internal issues by running them through a revenue equation.
How often does it happen? * How much revenue do we lose when it happens?
I’ve found that more than half the time that someone on my team comes to me with a critical internal issue, and I ask them for this data, even a guess, they don’t know.
This is fine. Because the first step in fixing the issue is prioritising it against the hundred other issues that are coming your way. And the first step in prioritising is putting the mechanism is place to capture that data. Try that first, then when you see a pattern, measure and act.