When it's time to undo 'minimum viable product' culture
When you launch a startup, you have to build a 'Minimum Viable Product'. You have to build several.
In Voxgig, we started with a newsletter to validate the market, and then a search engine to validate individual user interest, and then private trials to validate business interest.
This has all worked out wonderfully. Or has it? The problem is that it has worked. Too well. You may be familiar with the concept of technical debt. This is the name for the logical and justifiable decision to build your MVP using technology that won't scale efficiently. It's the only way for a small team to get things moving and get into the market. But that's not the problem I want to talk about today.
As an aside, in case you're an engineer, and feel technical debt cannot be ignored - I agree. We chose to build our system using microservices from day one, and that has helped contain the infection.
We are now replacing older services with shiny new scalable ones, migrating our data schemas, and adding all sorts of quality assurance steps to our continuous delivery process. If you really want to get into the details, it's my main technical conference talk topic for 2019 and a quick Google or Twitter search should point you in the right direction. And yes, as a conference speaker, I'm absolutely eating my own dog food and using our platform to plan and manage those speaking engagements - finally. No more planning spreadsheets.
The unexpected challenge that we face is cultural. I've been banging the drum about having a Minimum Viable Product philosophy so hard, and so relentlessly, that it has become quite embedded in our general approach to pretty much everything. Which is great and effective, but will not serve us well as we move into the live production phase of the business.
Once you have lots of real customers that rely on you to make parts of their business work, once you become mission-critical, you have to change. On the technical side this is not rocket science, and I've been through transition like this before, and helped customers go through them. But technology is not culture, and transitioning a startup into its next phase is hard.
What needs to change? First we have to shift our language. I've been fond of saying things like "good enough is good enough". That's very powerful for creating an MVP mind-set for everything. It means, for example, that it's more important to get the newsletter published on time, than it is to make sure every last grammar mistake, or visual glitch is fixed.
But now we need to start using new language, and asking new questions: "Will it scale?"; "How can we create process to get the quality right?"; "What should we measure?". You can't overcook this - we're still a startup and we still have limited resources, so 'perfect is the enemy of done' is still true (and that's a catch phrase I won't be giving up soon - if you work for me, cheesy catchphrases are one of the perks.). The language that you use is a powerful force on your patterns of thought. This is as true for individuals as it is for groups. So many startups, as they grow, veer into bland corporate language because they know they have to leave the MVP days behind, but haven't really put any thought into the new language they need to use. I only acknowledge the challenge here - as yet we've done very little work on this.
Another aside - if you doubt the power of language to make a real practical difference to business outcomes, try doing long division with Roman numerals. I'll wait. Our decimal system is a much better mathematical language because it lets our brains do more with the same number of neurons. The philosopher Daniel Dennett (YouTube is your best bet) has a great catchphrase for this: "You wouldn't build a car with your bare hands, so why are you thinking with your bare brain?"
Second, we have to invest time into designing and refining our processes. But in an ironic twist, we need to use Minimum Viable Processes to move our product out of the MVP phase. If we tried to implement detailed processes from day one, we would over-design, they would become embedded in our systems, and we'd be stuck with them. Our ability to adapt to the market would be badly constrained.
We can apply the same principle to our processes that we did to our product. First you build something that just works, and then you adapt it to meet your real evolving needs. You never develop too much of an attachment, and you remain prepared to throw away the parts that are failing, or just obsolete, and redo them.
Jeff Bezos, the founder of Amazon, has posters all over his offices that say 'It's Always Day One' (The official Amazon blog even has this phrase as it's title). I think this is what he is getting at. Of course, the day will come when we leave Minimum Viable Processes behind, and then we'll have a new challenge that all large organisations face - staying flexible. But that's is another year's problem.
Third, and finally, we have to expand the team with specialists who can focus on specific parts of the business. In the early days of a startup, everybody cleans the toilet. We all still do. We are still a team of generalists, and proud of it. But over the course of the next 18 months, we will need to hire people who have made certain things their life mission. Generalists can't do this, because they're good at something else - being generalists.
For another dose of philosophy, you'd do worse than reading that classic little book 'The Specialist', by Charles Sale. You'll never look at an outdoor privy the same way again, nor forget that no job is simple once you really get into it, and want to strive for excellence.
Search engine statistics: in our database of technology conferences we have 2,231 conferences, 6,146 speakers, 4,953 exhibitors, and 973 venues. At the moment this data resides in our search engine (we use vespa.ai - it's awesome and does machine learning recommendations out of the box - it's the search engine behind Yahoo Finance, which was open-sourced in 2017), but as we move to an integrated system for production, we now need to import all this data into a structured database, and set up new data flows to maintain the data. This is the 'boring' work of scaling the technology engine of a startup. It would have been a mistake to expend development effort on this in the minimum viable product phase - a search engine can double as a pretty good database. These are the kinds of practical tactics you adopt in the early days, but need to move beyond when you start scaling.
Marketing update: speakers newsletter - 5,926 subscribers, open rate 12pc. So close to 6,000 - another milestone to celebrate soon. EventProfs newsletter - 550 subscribers, open rate of 29pc (heading to 'normal' levels), and the podcast is at 70 downloads.
I'm not happy with the way we're measuring the podcast, but our marketing team doesn't really have time to look at it, so we'll keep using libsyn.com (our distribution service) metrics for the moment, even though they seem to be under-counting. Another startup fire that has to burn for a while.
Richard Rodger is the founder of Voxgig. He is a former co-founder of Nearform, a technology consultancy firm based in Waterford