4 rules for greenfield product development
Gall’s Law states:
“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”
Whenever I have the opportunity to work on a greenfield product, I find it helpful to keep this in mind. Gall’s Law helps advise a basic checklist I follow.
1. Understand why this solution is 10x better than an alternative
This starts with first understanding your customer deeply. Sometimes you or someone on your team is the customer. This is ideal. Other times your team has a clear line of communication to the customer base and/or rich data on it. This is great, especially when paired with the first scenario. Whatever it is, know who your customers are, what problems they face, and why your solution is 10x better than an alternative. Many times you cannot possibly know this until you throw some ideas out into the world and see which of them stick. This is why it’s important to keep most of the ideas in your product simple.
2. Avoid premature optimization, unless…
Once you know what makes your solution 10x better than an alternative, you can focus on that. It’s your core value proposition. You’re still going to want to keep your product and its code as simple as possible, but there is a combination of factors that I believe can act as an exception for complexity:
a. The work you’re doing is in a well-established “10x” area - the part of your product that makes it special.
b. You have already done the simple version of this work in the past and know exactly how to leverage that experience to build the more robust version without the timelines or future maintenance costs burying you
c. You know without a doubt that you will have to quickly support or scale the work you’re doing imminently
Keep in mind that it is extremely tempting to stretch one or more of the factors above. Founders or stakeholders will claim with certainty they know that their 10x factor is and how much it will need to scale in the first few months of product usage - despite not actually having any objective evidence of either. Engineers will claim they know exactly how to handle the more complex version of an implementation - despite never having done it in production before. Watch out for these red flags.
3. Find a product-centric leader with tech skills
Unfortunately, many highly technical folks - even the leaders - become tempted to view a greenfield product opportunity as a skunkworks project. The autonomy provided and the excitement around it becomes an opportunity to not only create a great product, but to experiment and engage in personal enrichment. This leads to a lot of pet projects and lost time.
If you make sure your technology leadership is more passionate about the product than the recipe, you will be focusing on what matters most — getting the end result you need without going overboard in the process.
4. Consider clever ways around complex technology requirements
Not all ideas that seem complex need to be validated using technology that is complex. It’s a dirty little secret in the startup world that what seems like an impressive piece of technology on the outside is often a patchwork of prototypes and technologies that don’t scale on the inside. I’ve seen Google Sheets used as a backend database with built-in business intelligence capabilities. I’ve seen technology branded as “AI” that is really just farmed out to people behind the scenes - just to make sure the concept works before investing in the AI itself. Tactics such as these can really help to validate and iterate on a greenfield product without optimizing the technology prematurely.
Breaking ground on a greenfield product? I hope the checklist above helps keep things as simple as possible while allowing you to focus on the challenges that truly matter.