Learn to walk before you run (and save time, money and trouble)

Coordinating your service

There’s little doubt that in an ever-changing startup environment, timing matters. Especially during the post-MVP period and scale-up stage, where gaining the client’s favour and loyalty is so crucial for cultivating growth in product awareness.

Nevertheless, for better or for worse, it is common for a startup to use different software houses/developers for the varying segments in service development. Actually, it strikes me how often we’re asked to form a product team and estimate on what are very loose terms. “Only add a few functionalities” or “just fix a couple things” we often hear. Whilst for a developer familiar with the source code this may be a walk in the park, it is certainly not so for a new team. One unfamiliar with the project must spend hours analyzing each task in order to determine the best approach. And the result? Estimation vs realization disparity, frustration, decreasing confidence and leveraged risk. Here’s where both money and momentum are lost. The wellbeing of all co-operation strongly depends on the mutual understanding of those involved: how something works (or is supposed to work) and how you, the brains behind it, understand its nuances and challenges.
This is what I call the walking phase - so important before the real jogging starts!

Two types of customers

Building an MVP

When looking for a partner to help you through any given stage of a product’s lifecycle, often there is already an initial notion of what needs doing, at which point one of two scenarios can usually be distinguished. 

The first involves a founder at the beginning of his or her solution-building journey, where most likely some anxiety will be suffered despite one having adhered to the principles of proper startup development. This is where I try putting myself in his or her shoes, just imagining the months spent polishing an idea which is then shot down when the assumptions upon which it is based don’t hold up to reality. I empathise with those who believe they’ve created a solution and finally manage to secure funding, only to be told the project will require more weeks of reconsideration, rediscovery and change. It is therefore important that both parties stay to the same path of understanding and discovery so that comprehensive, standardised documentation is established. 

The second scenario involves a founder with a strong attachment to the functional scope initially chosen for development.  Here, as evidence has shown, the most advantageous approach to adopt for both budget and market success is a pivotal one based on user insights. These insights are usually surveyed with a prototype built in the discovery phase and in most cases result in a narrowing of the list and a focusing on bare essentials. Counter-intuitive? Perhaps for some. Money and aggravation saving? Most definitely.   

Growing up stage

A scenario even less intuitive is one in which an established product is ready to scale (or rather the founders are). Such conversations usually begin with the assemblage of a small product team for equally-sized improvements and often come across as quick, MVP scope leftovers.  

But here’s a minor disclaimer: what a foreseeable, 1 to 2-month future really needs is only those small changes, ones which I’m perfectly capable of understanding. However, for most startups, this is a quick scaling stage. A stage in which incoming user feedback reshapes both the scope and the roadmap at a dynamic pace. 
Make no mistake, scaling up is sometimes even trickier than what came before: all startups aim high, so it’s extremely important to now prepare a foundation for the spike you’re expecting - which is hardly a case for building MVPs. And this is why I oppose the idea of simply gathering developers for coding without any prior preparation. It’s the same as before: a team that understands from the outset the nuances and ideas of what they do wastes neither your time nor your money figuring out how to initiate each task.

But don’t get me wrong. I’m not saying the product should be rebuilt from scratch (though this be the case once in a while). However, at this point in a startup’s lifecycle, the mindset must switch from dealing with ‘innovator’ user groups (who forgive much regarding product imperfections) to broader audiences that expect a more refined level of quality and ease. At times this will oblige us to shift our certainties if we’re to sustain a sincere connection with the product. 

Often as a narrowed version, the discovery phase here serves to decrease the risk associated with understanding your users and to pre-empt any technical challenges that might otherwise emerge further down the road.

Walk with your customers; learn to ‘pivot’

So the problem I address is akin to trying to run without first having learned to walk. (And good luck when trying to stop for a breather!) Regardless of an MVP being in its early stages or in need of quick expansion, experience and studies suggest that having an ability to pivot (to stop and change direction) is key to a successful startup. The notion is not flawless, however, it is far more efficient to identify errors earlier on than to suffer a longer learning curve with your customers. 

Eric Ries, the author of Lean Startup, proposed this definition: A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty.
I take two lessons from this: 

1. If you’re trying to keep double or triple-digit growth YoY, you will still be delivering a continuously renewable product often requiring significant alterations and changes.
2. That extreme uncertainty is not going anywhere for the foreseeable future, so you’d better get used to it. Therefore, develop the habit of gathering as much information as you can before coding anything.

This emphasises once again how the key to success is more about general attitude: to remain open to your users and to make decisions in accordance with their pains and gains. The most successful developers are ones who create solutions to problems through a sustained habit of regular user consultation.

The problem with running too soon

One need not wage war against all that was built prior to the software house enquiry. It's more about sticking to a budget through proper preparation - something particularly visible in the statistical evidence provided by those who adhere to this policy. In doing so, they avail themselves to more rapid upscaling even if it means taking one step back at the project’s outset.

In startups, knowledge means a lot - if not everything - and I strongly believe that a seamless joint project must start with all parties being on the same page. There’s no trick in it, it’s simply about being as informed and as enthusiastic as any founder will be. And this can take time. As the saying goes: nine women can’t make a baby in a month.

Summary

Yes, the time you spend working with non-coders on the discovery phase may bear costs. At times, non-negligible ones. But to me, the maths are rather simple. If you’re to spend tens or hundreds of thousands in whichever currency, a 10-15% investment in significantly decreasing risk suddenly seems quite sensible. Better to run a shorter path, no? 

Or perhaps you’ve had a different experience and completely disagree. If so, feel free to ping me on LI for an exchange of viewpoints - knowledge is everything!