Product Development vs Product Creation: The Age of Assemblers Is Here

Early stage founders are caught between the race for tech talent and a race against time.  

Software engineers in India and Southeast Asia are increasingly scarce due to today’s red hot tech talent market, yet startups need to turn their ideas into products as quickly as they can. Time to market is crucial for testing a product hypothesis and product-market fit.  

At Surge, Sequoia India’s rapid scale-up program for early stage startups, we partner with 40+ early-stage companies every year. In addition to funding, our team helps founders think through their product and recruit their engineering team. Sequoia India & Southeast Asia also partners directly with seed stage startups, and our Technology and Talent teams work closely with them too. While It’s always been hard to find great software engineers, designers and product managers worldwide, it’s clear that growing demand from our region alone is fast outstripping supply. Building out a technology team is getting tougher day by day.

Can we change this? Probably not. Can we change our approach towards building out technology products? Most definitely yes. 

Early-stage founders need to start thinking about how to create products with fewer people. The discussion around ‘build versus buy’ isn’t new.  But we think it goes deeper: it’s about reframing the whole product development process as one of product creation. The traditional approach to product development starts with building the team. When we look at this from a product creation perspective, the focus shifts to the process of assembling the product itself. 

Consider the Boeing 737, which has more than 350,000 components, hundreds of suppliers (at least 275 from India) who are manufacturing critical systems and components, including aerostructures, wire harnesses, composites, avionics mission systems and ground support equipment for some of Boeing’s most advanced commercial and defense aircraft. One of the most critical parts – the engine – is supplied by Rolls-Royce. The process of bringing everything together is a masterclass in efficiency; a typical Boeing 737 plane is assembled in 11 days. Boeing has produced an average of 415 737’s per year over the last 10 years – that’s more than one plane per day.

It’s pretty clear that the age of assemblers is here. We can’t build everything, and we shouldn’t. We should build what we must and buy the rest.

In the age of assemblers, builders won’t win anymore

Today we are already using Open Source frameworks to power our products. When you use any of the popular frameworks such as ReactNative, NodeJS, Django, Ruby on Rails or SpringBoot, you leverage the power of the many open-source components embedded in them and the hundreds of utility packages available to make tiny but important tasks in a developer’s life easier. Software engineers are builders by nature, and even with open source  and no/low code tools, we don’t solely assemble. Our own written code typically makes up about 10% of the entire code base. We still get to build something. 

Yet, many developers persist in building many readily available components instead of buying them. It’s like reinventing the wheel.  As Ian Malcolm, the chaos theory guru portrayed by Jeff Goldblum in Jurassic Park, famously said, “We are so occupied by whether we COULD, that we never stop to think whether we SHOULD?” And this question becomes very important due to the fact that a product is built with many components, and today’s product should leverage as many different commoditized components as possible. 

Software development has to move on from being a builder’s forte to an assembler’s world. 

Following diagram depicts the product lifecycle and highlights the multiple components that go into a product, and a company, that should be built, enabled, and deployed during the lifetime of the product journey.

This is true of both a startup and the product engineering team as well. There are some components that provide value addition to the company processes, such as the People function (or HR), CRM, employee tracking, talent acquisition, finance and others which provide value addition to the product itself such as automating delivery workflow, product management software, CI/CD tools, commoditized software services.

One of the most important decisions is “what to build”. Clearly, we can’t build everything; we can’t be experts in those many components. While we may not be able to pull off everything using no-code tools, we can buy many of these components to assemble them – and to achieve that, you don’t need an army of developers. Today we have a more mature SaaS ecosystem compared to a few years back, and so there are many companies that already employ hundreds of developers to solve those problems for you through their products and services. The answer to the question around ‘what to build’ should be defined by what’s core to our business.

There are multiple frameworks that we can apply that optimize for time by helping us zero in on the components which can accelerate development of a minimum viable product (MVP). Thinking through a process of defining core vs non-core has helped me in the past. Whatever way we can define it, if something qualifies as core then we will put people on it internally, and if not, then it either goes the route of ‘buy’, or we should be outsourcing it. But this is easier than it sounds. 

Build vs Buy

One of the techniques I found super simple in the early days in product building assembling is to use Wardley maps with all components laid out, and apply Wardley mapping techniques. Let’s look at a simple example – a simple photo app.  

If you start laying out components with app flow, it might look like something below.

Now, how can we arrange this in a way so that it can become easy for us to prioritize what to build?

Start by defining what’s core to your product. Think about what’s extremely essential to your product, and serves as the touchpoint, from the customer’s point of view – versus what’s non-essential and easily replicable. Map these on two axes: visibility to customer and commoditization of components. Here’s one example.

Build whatever lands on the intersection of your core idea and visibility to the customer. The rest can be purchased. The caveat is that while this technique works for the early-stage product life cycle, if you want to apply it to later-stage products you need to decouple components and build abstraction across product components. You’ll also need to consider many other factors, as it’s no longer as simple as whether it’s a commodity or not. Here are some key considerations later stage startups will need to add to their build vs buy matrix:

1. Budget
2. Optimizing for time
3. Maintenance 
4. Data & App security
5. Compliance and Risk
6. Economies of scale
7. Does it make sense to build at some point but not today?
8. Ownership of Data

While things like Data Privacy and ownership of data are important factors, relying on well-established vendors for purchasing software takes that problem away. 

Summary

Here’s three key points to consider as you start discussions with your leadership team on whether to build vs buy.

• In the early days, we are running against time
• In later stages, we are optimizing against capability vs capacity. 
• Use software engineering capacity as currency to spend only on valuable, moat-creating initiatives.

Sequoia India and Surge have partnered with many companies that provide software as service that can accelerate your product journey.  If you’d like an intro, reach out to me at ajey.gore@siteadmin.peakxv.com.