Sharing another excerpt from One to Ten. Enjoy!
**
Deciding when your product is “good enough” to ship is one of the most important calls you’ll make during the One-to-Ten stage. Ship something half-baked and you’ll have your engineering team fighting fires, your customers unhappy, your go-to-market staff demoralized. Wait too long and you risk over-engineering the product, lengthening the time to get customer feedback, ultimately shortening your runway. Do not delegate this decision to your team. You will own it either way.
Decide When Your Product is Good Enough
How do you know when it’s the right time? In hardware, you may be using a Product Lifecycle (PLC) framework, also known as the V-model. It builds in accountability, via periodic design and program reviews, and defined entry/exit criteria for each stage.
Besides a formal PLC framework, use the following heuristics to decide when to ship, that is when to exit beta and move to GA (Generally Available):
Churn reduction / Table stakes.Address the reasons for churn of any beta customers or else you’ll constantly “fill the bucket” with customers only to have them leak away over time. Early customers churn due to a lack of table stakes features or because they’re not getting enough value for the existing product relative to their other options (see Bossa Nova / Walmart). Consistently losing deals involving your ICP is a good indicator that the product isn’t quite ready.
Uptime or Performance KPIs. This is self-evident. If you’re hitting the metrics you need to hit to add value to customers, you are there. The KPIs can involve cost savings, revenue increase, or just usage of your platform. As for uptime, every industry is different. Whereas robotics deployments may get away with 95 percent uptime, mission-critical systems of record need to hit at least four nines (99.99 percent or higher).
Repeatability. How easy is it to stand your product up in multiple locations, customers, instances? You may still be building your own hardware and selling these as revenue units, but do you have a path to being able to use a contract manufacturer? Is your supply chain robust enough to handle the additional volume? Are your integration points robust enough? There isn’t one metric to assess repeatability. Rather, conduct thought exercises to stress test your product: If your largest customer grew 2x tomorrow, what would happen? What if you signed all of your pipeline in the next month? If that kind of growth would break your system or involve a lot of manual work, it’s a good indicator of tech debt to retire.
Tech debt and Scalability. Acknowledge the debt you have and how it might impact churn or scalability. For instance, maybe your team members were like “squirrels in a box” scurrying to solve problems in the background for your beta customers when these tasks should be automated. You can brute force this for a while, but eventually you’ll need to spend engineering cycles on scalability.
Customer happiness. Your pilot customers are important barometers for product readiness. Don’t just ask them, see how they’re actually using your product.
Team sentiment. By that same token, take the temperature of your team. I put a lot of stock in team confidence. Hopefully you’ve created a culture where they’re comfortable offering candid feedback. The worst outcome is if they tell you what they think you want to hear when they don’t believe in the product’s readiness.
Conway’s Law: Pay Attention to the Integration Points
In 1967, computer programmer Mel Conway introduced the adage: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” In other words, you ship your organization chart.
There is no ideal way to organize teams. You will incur tradeoffs any which way you go about it. Regardless of how you’ve organized your company, pay the most attention to the integration points, where the work product of different teams comes together. That’s where the most system failures happen because each team may be locally optimizing while achieving a suboptimal result at a system level. That’s also where Systems Engineering plays its valuable role in taking a holistic view across the components and making the tough tradeoffs.
Shoot the Engineer
Engineers tend to want to, well, engineer stuff. They’ll especially want to do so if they’ll be on the hook for customer support. Sometimes they just like tinkering when there’s no real difference to customers. I once met an engineer who, late one night, was showing me his work, his tinkering. I asked him when it’d be ready to ship. He hemmed and hawed and then talked about shooting the engineer. Huh?
He told me about an old saying: “There comes a time on every project when you just have to shoot the engineer and get it out the door.” This is natural. Engineers tend to want to optimize and develop what’s next on the roadmap. You’ll want to give them space to do their work and air any misgivings they may have so their voice has been heard, balanced with the clamor from customers and sales to get the product out there. Use the heuristics above to come to a decision that the product is ready to ship, ideally bringing your team along the way. If there are still doubts, ultimately it’s your job as CEO to understand the risks you’ll face in shipping the version you have and draw the line as to what’s good enough to ship. And once you’ve made the call, once you’ve shot the engineers, you’ll need to own the results. You’ll lose your team’s respect if you don’t.