Software Culture has this theory of “Rapid Development”; that a software team can quickly prototype a concept or idea and have something that the business can show to customers to get initial feedback on. It’s a great theory, one that is certainly doable. Where it breaks down, however, is when it meets Corporate Culture – who have a different theory. Corporate Culture typically believes that a prototype is an initial investment in a software deliverable – a “Rev 1 Alpha” so to speak. And that the prototype is somehow capable of being tweaked and going to market.
This collision of theories and practice frequently results in nightmares for all involved: software developers who are trying to retrofit something that was tossed together and marketing, sales and business that is trying to get sales going on something that for all practical purposes, is Vaporware.
So, why does this happen? Let’s look at what Rapid Development means to developers and compare that with what it means to business.
To a Software Developer, Rapid Development, or prototyping generally means:
- Working from an idea or vision, not from a design spec
- Using standard building block components with some wireframe code patching them together
- Using a file of data or a repository that is quickly thrown together
- Hard coding (instead of algorithmic calculation) any business rules or logic
The result is software that was designed and built for the near-term, meant to be discarded and replaced by something well-designed once budgets are allocated for it. Meaning that it is specifically not designed for the long-term. It’s been patched and hacked together with no intention of any of it, other than the concept, being used in a market product.
The business side typically has the following outlook on prototypes:
- We can prove it is viable by selling it
- When we sell it, the customer wants it – right away
- When you show a potential customer something awesome and ground-breaking, they usually get excited
- When you tell an excited customer that what they’ve just seen is a concept or prototype that isn’t viable, they either get cold feet or start hassling you to get it to them
The result of the business’s experience is that there is money to be had by getting this into customers’ hands right now. Whether the product will work well or at all for the customer is of secondary concern to closing the deal.
This results in Software Development being pushed and harried to deliver the prototype for market. Everyone in the business pipeline gets antsy and pushy and goes into fits when they are told they can’t have it right away. The Developers, now in desperation, usually end up explaining that “sure, the prototype works, but only within certain parameters” – thinking that business will be logical and say something like “oh, we wouldn’t want to deliver that, when can we get a market-ready version?”. But that is not how it goes down. Business instead says “Well, if we give them the prototype and take their money, by the time they receive it, get it installed and configured and try to start using it, we’ll have a Rev 2! Right?”.
And so it goes. What ends up happening is development tries to figure out how quickly they can retrofit pieces of the prototype and make it deliverable. The CEO is probably breathing down their necks by now and they end up agreeing. The prototype gets sold. Rev 2 is released 3 weeks later and suddenly marketing, customer service, sales and retention are all demanding features and changes in order to keep customers. Development responds by thrashing on the prototype even more and tacks on a bunch of garbage to get the features and functionality that business is screaming for. Suddenly, there are 200 customers using the product and while they’re happy to have some useful features, it has latency issues, annoying bugs, partially implemented features and for about half of the customers it doesn’t work right at all.
A year or two later, the prototype codebase is still in use but it looks nothing like the prototype and everyone in the company hates the software and wants it rewritten. Business isn’t willing to commit the budget for a full rewrite because about 80% of it works about 80% of the time and the rest of the time developers are able to kludge something together to make it work.
This may seem like a ridiculous scenario, but it plays out something like this much, much more often than most people realize.
There are two principles to learn here:
- When you put garbage in (which is what prototyping is), you get garbage out. GIGO – it’s a thing.
- Software designed for the near-term was never intended or expected to work for the long-term.
There’s a kind of a 2.a. here as well: When you are ‘fixing’ software as quickly as you can, based on customer feedback and bug reports – you are fixing for the near-term. Near-term fixes like this are hyper-focused on the context of the problem and are therefore never long-term fixes.
So how do we avoid this scenario?
This is tough because the root of the scenario is based in core differences between developers and the business. Developers love to create and envision new solutions. Business loves to sell and put products in front of customers. To fix it requires changes in perspective on both sides.
When putting out a prototype, development needs to communicate clear expectations to business. One way to do this is to clearly mark and identify the prototype as a prototype. Put “Prototype – not for public release” in the header or somewhere that any customer viewing it will immediately see. It will also remind anyone in business using it or demoing it that it is not a market-ready product.
The business will often want to show prototypes to customers to get feedback on them and to vet them as a viable product that they can sell. This is an excellent tool to ensure that the business does not sink a lot of money into a product that won’t sell. It is also an excellent mechanism to find out what potential customers do and do not like about it, what features they want, what is redundant or useless to them, etc.
This is the Product Manager’s field. Business should understand that anytime a customer is being shown a prototype, the Product Manager should be present. This way the Product Manager can get feedback from the customer and can also clearly communicate expectations of delivery to the customer – without it being the sales person’s fault. The customer needs to understand that they are seeing this product early because they are a valued customer and their feedback is vital. Then they can still get excited about the product and when handled correctly, they begin to view themselves as already purchasing/owning the product because they are in early and are giving input on how it will be designed and work. When the product is ready for market and the customer is shown a demo of the market-ready product and see the features and workflows they specified, the sale is already complete.
Development needs to communicate to business that once the prototype has been shown and feedback collected, the entire prototype will be scrapped and the product will be designed from scratch. On the development side, that may not literally be what happens, but it figuratively is. The product will need to be designed from the ground-up and built for the long-term. This means that when the product is architected, all features and services it will eventually provide and/or consume are taken into consideration and the design will be created to handle multiple interface implementations and will be extensible for future unseen variances.
Once the architecture and design is complete, then a Minimum Viable Product can be built and released. But that is another article.
Being “quick to market” should mean putting together a prototype to get the concept in front of potential customers, get their buy in and ownership of the product, take all feedback from the prototype and architect and design a to-market product that is built for long-term existence and can be extended and maintained and then get an MVP into those customer’s hands in exchange for their cash and testimonials.