How to Build Product Fast

The secret is in how fast you fail, learn, and iterate

DEV.BIZ.OPS
Feb 2 · 8 min read

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.

Mark Birch storming the Great Wall of China
Mark Birch storming the Great Wall of China

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.

How to Build Product Fast
How to Build Product Fast

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 allows them to implement lots of processes and guardrails. 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 key to building quickly is smaller releases and faster iterations
The key to building quickly is smaller releases and faster iterations

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:

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

Image for post
Image for post

Speaking of MVP’s, I recently spoke about how to build MVP’s quickly at the B2B Growth Bootcamp sponsored by AWS and HubSpot. I shared steps in planning and building your MVP and my colleague Satish walked through a live demo coding an app. I will share a link to the replay once it is posted.

Image for post
Image for post

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!

Image for post
Image for post

I also wanted to post these awesome startup 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!

The Startup

Medium's largest active publication, followed by +771K people. Follow to join our community.

DEV.BIZ.OPS

Written by

Thoughts on developers, digital transformation, enterprise agility, community building & software engineering culture. Author 👉 https://twitter.com/marksbirch

The Startup

Medium's largest active publication, followed by +771K people. Follow to join our community.

DEV.BIZ.OPS

Written by

Thoughts on developers, digital transformation, enterprise agility, community building & software engineering culture. Author 👉 https://twitter.com/marksbirch

The Startup

Medium's largest active publication, followed by +771K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store