To be successful, software start-ups need to develop technologies quickly. They must be extremely responsive to their lead customer's needs and be willing to add functionality to a product at any given time. However, as they become successful and increase their customer base, their ability to develop functionality at the speed of thought might lead them to failure.
The delivery metrics across your large-scale transformation program look strong. The closure report is signed off. The steering committee congratulates the team. And then, quietly, the organization continues doing things the old way...
“Done” is one of the most powerful words in agile. It brings closure. It marks progress. It gives us the satisfaction of checking a box and moving on. But what happens when “done” becomes hollow, and the value is nowhere in sight?
Employers often favor candidates who already have real-world execution experience. That leaves many capable professionals stuck trying to break into a field that increasingly expects them to already know how to operate inside it.
Landing a lead customer is one of the hardest milestones a start-up will ever face--second only to landing an investor. In order to achieve this objective, they must be willing to bend their development process and make exceptions to the rules that normally apply to software development. Your lead customer does not care whether or not you're product is in its Beta phase. If your solution does not solve their problem, you have two options. Add more functionality to your product, or go do business elsewhere. And when they ask for more features, they don't mean now. They mean right now!
CEOs of great start-ups understand this inevitability. Perhaps it explains why some companies become successful without any formal development process, written software requirements and/or project manager. Does it mean that software development processes have no use in start-ups? Absolutely not, but if I'd have to bet between a start-up doing everything it can to win a lead customer and one trying to win the Malcolm Baldridge award, I'd put my money on the former any time!
Once your lead customer has invested in your product based on its (perceived) ability to solve their business problem, their No. 1 concern shifts from functionality to reliability.
Reliability is a broad term and means different things to different people and industries. From an engineering perspective, it means the extent to which the system will execute without failure for a specific period of time. From a statistical perspective, it means the extent to which a measuring procedure yields consistent results over repeated observations. For the context of this article, reliability will encompass the elements of quality, stability and consistency, and will be defined as the assurance that a software component will perform in a specified manner for a specified time under a set of specified conditions.
Up until now, worrying about reliability would have been detrimental to your success. Reliability presents an important cost of opportunity, and assigning scarce resources to this non-functional requirement would have meant you would not have been able to load your solution with the features your customer demanded. But the landscape has changed. You now have a lead customer. Your priority is not to sign him up anymore, but rather to keep him satisfied, and that means making sure your product is as reliable as they expect it to be.
While all successful CEOs understand that adding functionality to a product right now is unavoidable in order to land a new customer, they must also understand that keeping this same customer happy requires a different strategy. It requires you to strategically and gradually shift your focus from adding more functionality to improving reliability.
If I were merely a writer with no actual start-up experience, I would conclude this article now with the following summary: Great start-ups become successful because they efficiently add functionality to their product, but eventually fail because they never make the transition from adding functionality to improving reliability. While this statement can prove to be absolutely true, reality is, having only one customer is usually not profitable. In order to become truly successful, most software companies need to acquire multiple clients. And the likelihood that the first release of your product meets the requirements of your next set of customers is nil.
You're now facing a dilemma: keep focusing on adding incremental functionality to your product in order to sign additional customers, or shift your focus to reliability in order to please your existing client base.
The terms strategically and gradually three paragraphs above were not bold by accident. They were highlighted because they are critical to your success. Instantly shifting your focus from functionality to reliability will be as devastating as continuing to ignore reliability altogether. You have to be smart about it.
Unfortunately, there is no secret recipe to explain how this gradual shift should occur. There are too many factors affecting your decision. Do you have a budget to hire additional employees? When is your lead customer expecting to go live? When do you plan on acquiring new accounts, and which incremental features will they require?
Balance is Key Just like most other principles in life, balance is key. Maintaining that code-like-hell software development process will certainly not result in the quality your existing customer base is expecting. On the other hand, forcing your R&D team to suddenly follow a rigid quality process might slow your development significantly and affect your ability to close new deals.
My recommendation is therefore the following:
Split your existing product in two releases: a stable release and a development release.
Improve the reliability of the stable release until it meets your lead customer's quality expectations. Limit the amount of change requests to an absolute minimum.
Enhance the development release with value-added functionality. Focus on solving your future customers' pain points.
Slowly and gradually improve your software development process. Encourage your designers to think about quality in every phase of your process, not just in the post-development phase.