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.
External prioritisation: The wish list
If you’re lucky (or good), you’ll receive just as much inbound from customers and potential customers requesting features, demanding features, and even rejecting the product outright because of one small issue that is seemingly easy to fix.
I’m a fan of making easy, customer-facing fixes on the fly, but too much of this not only overloads your resources, it builds technical debt quickly.
So for every new feature or feature set we consider, we run it through this similar equation:
What’s the opportunity in dollars? * What is our confidence level that we’ll realise that opportunity?
The left side is how many current customers will pay more and/or how many new customers will this push to close. The right side can be a little arbitrary, but if you have data around customer engagement, or you can go get that data by talking directly to your customers, that confidence level becomes a little more quantifiable.
Just keep in mind that the customer isn’t always right. Make sure your customers’ vision aligns with your vision for the product before giving them everything on their wish list.
Guessing is OK. Data is better.
One internal process I always launch with is the ability to collect data that can help my organisation quantify both the internal and external equations. Even if that data isn’t at a low level of granularity, an educated guess is better than a wild guess.
You don’t have to track every movement of every customer right from day one, but you should know the aggregate totals of conversion, engagement, churn, and an idea of what your customers think about your product.
That last one could be an NPS or a survey, or even a quick rating check, as long as it’s something you can use to set a baseline to periodically check your progress against.
When all the numbers come together, you’ll start to get a sense of measurable customer value. This is your guide to product-market fit, and it’ll tell you how to spend your time and your resources to get there.
This article was originally published on Medium by Joe Procopio
Joe Procopio is a multi-exit, multi-failure entrepreneur. In 2015, he sold Automated Insights to Vista Equity Partners. In 2013, he sold ExitEvent to Capitol Broadcasting. Before that, he built Intrepid Media, the first social network for writers. You can read more and sign up for his newsletter at www.joeprocopio.com
If you want more direct advice and answers, look into Teaching Startup.
