This article is a part of a series of pieces on digital innovation, accelerating change and the rise of the coded business from innovators in the Chef community. This article is by Kate Matsudaira, founder of Popforms
Businesses have always needed speed and scale to meet customer demands. Today though, the kind of speed and scale businesses require to stay ahead of voracious consumer appetites and competitive offerings can only be achieved through a combination of: automation; internal culture shifts internally to integrate developers and IT functions closer together and more closely with the business; the use of commodity hardware; and a willingness to offer and embrace imperfect products. Then, and only then, will companies realize the benefits of moving quickly to deliver product, and also in unlocking innovation in this process to generate new revenue streams.
For this to work, CIOs and CTOs must fully understand the business. They can no longer just be experts in technology. That’s not enough. For IT to evolve from a cost center to a revenue generator, IT must be integrated and engaged in the enterprise – large and small enterprises alike.
Take a specialized candy company, for example. Before, it would not have been economical for this kind of business to scale at speed. But now, with minimal expense, it can acquire the compute cycles it needs, automatically deliver working code into its expanded production environment, and keep IT costs down through automation.
Also, with the cloud and SaaS, costs for technology are way down – or, in some cases even free. This commoditization of technology is hugely positive for IT and its new role in many companies. Technology is no longer such a massive sunk cost. CIOs and CTOs can focus on meeting the quickly changing needs of internal and external customers to drive the business and growth forward and upward.
That said, the pressure is on to deliver new code and new software solutions much faster, customer demand is relentless and escalating in intensity and speed. There is an almost immediate need that has to be fulfilled each and every day. And only automated and continuous delivery of code can meet that need in businesses of all sizes. It’s clearly a competitive imperative – and one that businesses must now approach differently as demand for “now” replaces demand for “perfect”. I advocate building v1 fast, then building v2 right. This gets product in the hands of consumers quickly and allows the team internally to answer pertinent questions that impact the long-term success of the product including:
- How quickly will the data grow?
- How fast will writes need to be?
- Will it be feasible to write directly to the data store, or do you need a queue to manage
writes?
- What will the throughput be, and is it enough?
- Will the system scale with usage?
This “Lean Startup” approach to software development – which advocates fast iteration and data collection to hone in on the right product and requirements as quickly as possible – is all about figuring out what customers will use and then building those things. And these same ideas can be applied to the technical ways we build products, too.
Put another way – similar to creating a minimum viable product (MVP), build the minimum viable technical implementation that meets the business goals (the product can meet current usage requirements and performance).
Most engineering teams have been taught to think about the software design and architecture from the beginning and build something that can scale. However, if you don’t have any customers yet, scaling really isn’t your challenge. So, in some ways, designing for scale when you don’t have to scale yet, is solving the wrong problems.
Of course, I am not advocating doing something careless, or writing bad code, but don’t over- engineer or solve for problems until you have them.
In many ways, this process is about looking at the problems differently, and instead of solving the “big” problem, focusing on speed and efficiency – getting the highest ROI (return on investment) for your development resources.
So you modify your development process to ship the first version quickly, and then once the v1 is out in the wild, plan to start on the v2 right after.
Then your v2 can address all the problems with the first version of the product. You can improve the usability, cut or add features based on customer usage and feedback, pick the right technology and libraries to power the product, and spend time writing acceptance tests and unit tests that are unlikely to change. And, from a business perspective, you get the product out there faster, so it is easy to understand if it is going to drive revenue and success.
This process makes sense because it:
- Reduces the risk of over-engineering
- If you build the wrong thing you can correct it
- Chances are you will get to market faster
So what are the downsides?
- Total time to build is more than if you just got it right the first time. And operations can be a headache.
If you do embark on this journey, here are some pointers:
- Get management buy-in
- Measure everything
- Understand that the v2 will take much longer than the v1 and set expectations accordingly
- Have a tight feedback loop with your customers
- Make sure v1 and v2 are celebrated equally
This is the formula organizations need to follow to be more competitive in today’s business of environment of rapidly evolving technology.
