You cannot actually see the Great Wall of China from space. For a long time, this myth was floating around that the wall is so significant, that you could see it from the moon. Alas, even from low Earth orbit, a person could not spot the Great Wall with the unaided eye.
What is remarkable about this seventh wonder of the modern world is that it has existed for over 2,600 years. Started somewhere between 700 and 600 BC in small sections, it progressively became more significant with the Emperor Qin around 220 BC with construction continuing off and on till the end of the Ming dynasty in 1644. This was a massive undertaking and achievement.
Many architectural wonders have taken a long time to complete. The Leaning Tower of Pisa took over 300 years to build and stabilize into the crooked structure we know and love today. Angkor Wat took 400 years to finish. The Taj Mahal was a 21 year long project and required 20,000 workers to complete this incredibly grand structure.
In the modern era, we have found ways to build things faster. Heavy duty machines using modern day conveniences such as combustible engines and electricity reduce the manpower needed. Our knowledge of materials and refinements in our understanding of physics enables us to test and optimize designed. This allows architects and engineers to design complex and resilient structures in factions of the time using computers and software tools.
Building software tools has also become much faster. Going back over 60 years ago, most code was handwritten in assembly language, a slow and laborious process. Compilers were only just starting to become commonplace. The very first commercially available compiler was released by IBM in 1957 for FORTRAN which itself took 18 person-years to create.
Programs back then were in one sense simpler. Yet they were also quite sophisticated in how they most efficiently used the limited resources available to developers. With memory limited it took a lot of creativity and patience to build an error-free program.
Nowadays, thinking about memory allocation and writing to registers is ancient history. If you do it at all, you are either doing it for a computer science class or you are working at the operating system level. Even compilers have become a relic of the past. We don’t need to convert readable code into binaries, we just package changes, libraries, and dependencies together and push to production.
The speed by which we can build stuff is remarkable when you think about it. The other week, I got a domain, opened a new account on AWS, configured Amazon Lightsail, and had a working WordPress instance running in ten minutes. In 30 minutes, my new website was totally customized. I could have even gone the full no-code route using Amazon Honeycode to load a spreadsheet with data and publish a working mobile app. I could also go the other direction, pull up the AWS Command Line Interface and use Amplify to build a complete end-to-end app and pull in AI/ML predictions from any number of ready-made AI services for serving personalized recommendations or real-time analyses.
The question of how to build something fast has pretty much been solved. At any level of technical competency, whether experienced developer or non-technical hobbyist, anyone can build apps. What was once the domain of those that can code, low-code and no-code tools like Webflow, Wix, Airtable, and many others have given everyone the power to build.
The real question then is not how to build fast, but what to build in the first place. This leads to the obvious follow up question then, is what we want to build worth building?
When I had my startup over a decade ago, my question about how to build fast was trying to address this question of why build it. I wanted to know who cared about the problem I was trying to solve, how big of an impact solving the problem would be, and how much people would be willing to pay to have me solve it for them. What I wanted and needed to build fast was a test to answer these questions.
Since my coding skills were rusty back then, what I built as a test were crudely drawn mockups. I would tool around in PowerPoint trying to build something that represented my designs, and later used a proper wireframing tool, Balsamiq, to help visualize features that I would show prospective users. About 90% of the time, my initial ideas were pure rubbish, but because I could make changes quickly, the cycles needed to iterate were fast, turning around feedback in hours or even minutes depending on how far off the mark I was on the feature.
Little did I know that what I was doing was Lean Startup before Lean Startup was a term. What I was calling my live user tests had in fact a formal name called a minimum viable product, or MVP. In the book Lean Startup by Eric Ries, an MVP is a "version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort".
Often there is the temptation to skip these iterative steps and focus on delivering as polished product with all the shiny features. There are various motives for why, from the desire to simply build for building sake to fear of expending effort on something that is not polished enough that users would outright reject the product or feature. Then there is the fact that the larger the organization, the more approvals, budget wrangling, and politicking needs to happen to even get started. It is easier to sell the slick product demo than the clunky MVP.
Perhaps the biggest hindrance to taking the iterative MVP approach to products and features however is lack of tolerance for failure. MVP’s are at their essence a good mistakes mechanism. Running through iterations of testing and feedback results in accelerate learning, with each iteration getting closer to a product or feature that best satisfies user need or shows positive outcomes. With a solid mechanism in place, you are able to make much better data-driven product decisions.
You might be tempted to call this mechanism Agile. That is a word that big, corporate organizations like to use because it gives them something to puts lots of processes and guardrails against. They can get certified coaches and implement strange rituals call Scrum and produce mounds of artifacts that have little to nothing to do with delivering a superior customer experience or better business outcomes.
Startups don’t need frameworks or coaches or corrupted words like Agile. A startup is a pure execution and iteration engine. Because processes, org charts, and reporting lines have not calcified the arteries of the organization, startups can go from idea to product market fit in a matter of weeks. Each iteration can happen in the span of a few hours. The build, test, deploy cycles can be as short as minutes.
The other observation about MVP’s is the tendency to overbuild. No one can predict the future. The more successful MVP initiatives therefore focus more on the ability to iterate and learn in the near-term with narrow changes than to push more complete and polished features. Working in smaller batches, releasing quickly, and measuring results is a more scalable and informed approach to achieving product market fit.
Indeed, your MVP may look like a disjointed, Frankenstein of an app. Reid Hoffman, the founder of LinkedIn, had this to say about early product:
“If you aren’t embarrassed by the first version of your product, you shipped too late.”
Being a successful company requires asking two questions. Will customers use your products and how quickly can you deliver something of value that is meaningful to your customers? These may seem obvious, but it not uncommon to get muddled responses from people I ask those questions to. The culprit often comes down to how the organization uses MVP’s to get clarity on these answers.
How does your company use MVP’s to develop products and features? If they are not using MVP’s, what is the process used to iterate and test ideas?
Mark Birch, Editor & Founder of DEV.BIZ.OPS
Speaking of MVP’s, I am going to talk all about how to build MVP’s at the upcoming B2B Growth Bootcamp sponsored by AWS and HubSpot. My talk is Feb 2nd from 2 - 4 PM SGT. I plan to share the steps in planning and building your MVP and then my colleague Satish will walk through a live demo coding an app. The bootcamp is free to attend and you can sign up here.
I spoke last month at Stack 2020, the big GovTech Singapore conference, on the topic of building internal developer communities in the tech culture track. If you did not see my talk initially, click this link to check it out!
I also wanted to repost these CTO positions based in London. If you are interested or know of someone that would be, definitely feel free to pursue or share.
Head of Engineering at Troglo - Seeking an experienced Head of Engineering developing and delivering on Troglo’s product roadmap to modernise healthcare through their sexual and mental wellbeing app . Read more here.
CTO at Pesky - Looking for a someone on the leadership team to define the technical architecture to support all aspects of the business and help deliver digital innovation to the British fishing industry. Click here to learn more.
CTO at Salary Finance - Want an inspirational CTO to lead the Salary Finance technology strategy and team, representing technology and engineering on the Senior Leadership Team. Find more details here.
Cloud experience for all of these roles is required and both Pesky and Salary Finance rely heavily on AWS. If you have senior engineering roles you are looking to fill, let me know and I can include in the newsletter.
Want to learn more about DEVBIZOPS and read more hot takes about IT, technology, and working smarter. Receive our weekly newsletter by signing up to our Substack!