The start-up CTO — MVP?
The one about — ‘where to start and the MVP’
Right at the beginning of the start-up journey there is a need to define what will be the journey to your MVP — the minimum viable product. The first product or service you will launch to an audience. This is defined nicely here: https://en.wikipedia.org/wiki/Minimum_viable_product
Analysing the term, MVP, in reverse, the Product defines the thing, the service, the offering, the app, the interface you will offer. In simple terms you take a problem (or opportunity) and offer a solution.
The viability refers to something meaningful that offers value to the end user, even if it much less than the whole service you know you wish to create. We would likely consider a balance of the most compelling with the easiest to build as a proof of the concept.
And minimum finally refers to doing as little as possible. (I would add as well as possible). Not for reasons of laziness but to spend as little of your funds as possible whilst producing the best example of a portion of your whole idea.
Minimum Viable Product.
In this piece I am referring to the first stages of development of the whole company, but of course the definition of the MVP refers to a continuous cycle and can be applied equally to each new feature or service as they are created.
This MVP theory and practice is one of the balancing acts in the desire to produce a full fledged product and service and create a Big Bang launch moment — much as physical products would do — with the opposing perspective of proving the value of a base aspect of the innovation with a set of users before you go too far. This is certainly an investor view — “show me some proof of uptake and interest of your core proposition as a significant part of the evidence required to invest”. And indeed a likely start-up requirement catch-22: not enough investment at the start to develop the whole, and no new investment until I can prove the concept in real life. Each product will be very different, and there is no one answer. But some techniques and patterns can be applied to help decide what to bring to market first. What part of your service demonstrates the most value, will attract customers and crucially, will teach you what is working and what is struggling?
Much of technology is about engineering — the application of design, realisation and delivery to exact standards. But before this comes the art and science of product and roadmap. My personal belief is that the understanding, designing and architecting for the whole concept is a necessity that allows the roadmap to be drawn out and thus the MVP to be chosen. By this I mean to suggest you don’t limit your thinking to the MVP phase but design a much more detailed and fully mature solution. From that exercise, choose your MVP. You may find yourself producing a draft 3 year roadmap of your service — a roadmap as a way of sketching out all the elements of a service you would like to offer, spread over time and thus importance. Consider this as an exercise measured in hours and days, not weeks and months to avoid over analysing. A well considered but succinct outcome will determine the current thinking on where this product will be at full maturity- or at least as far as we want to see at this stage.
Your MVP may be a complex set of requirements and elements you need to build even for a minimal service, but initially let us take a simple example. If we were setting up Auto-Trader today and looked at an initial board of all the possible features we might see:
“Authentication and Authorisation, Car listings, photo galleries, private and trader sales, favourites, auto-suggestions, messaging, content and articles, premium listings, European coverage, iOS and Android Apps, phone and tablet and browser, banking and insurance services...’
This is an unstructured list, so we need to provide some order. I like to sketch out the ‘dimensions of growth’. It allows a view to form of how you see the company using its resources to grow the enterprise over time with respect to priority. The above could be categorised in to Geographic, Devices, Features, Vehicle Types, Demographics, Foundations and third party services. Creating this graphically can help a conversation that will start to give a view to prioritisation across these areas. For example after an MVP what we will consider next? Is it more important to provide multiple platforms/devices or more important to take a single App Store application to multiple countries, or perhaps broaden the features first?
With a ‘view of everything’ as we know it today — a whole company group exercise would work well — we have all the material to choose our MVP based on desired timescales, budgets, the proof we are seeking to demonstrate and what we will learn as a result. Consider too, what does success look like, and how might we measure that?
In our car selling example we need to show that an audience of sellers would be willing to join our new service, list vehicles for a fee and see a positive result. There is no right answer here, so we select what would be the minimum but viable offering to excite our chosen audience. An example might be:
“We will go to market with an initial MVP limited to the UK mainland for trade sales or cars only from the top 20 manufacturers whereby listings are limited to 5 photos, 20 descriptive fields. The app will simply allow search by data fields and return results in a default price order and allow the use to see contact details”. Success will be x% of a y market and we will measure that in app downloads, new accounts created and cars listed and viewed/sold’.
If we look at how this works across the start-up it can illustrate the power of the approach — both the definition of the whole and the chosen first service development — for different perspectives and roles within. The CEO and board will have created this definition and it will drive the investor relations and approaches. The CPO (Product Officer) will embellish this to create a longer term initial roadmap of how the service will mature, the CTO will use it to set out the broader service architecture design and make choices about how and what to build initially whilst avoiding re-builds shortly down the track. The Sales team will understand the value proposition being created and what comes next and begin to produce their material. The Marketing team will be able to define their journey and specific support for the first offering. The CFO can begin financial modelling with assumptions being built based on this MVP and the broad roadmap that follows. The operational expectations and growth model can be defined. All of these perspectives help to ratify the approach and to support it.
Here is a three point plan I would consider when assessing your plan to release an MVP (as your first ever release, or indeed a new venture in a scale up and beyond):
What are you trying to prove? Does the MVP tackle the big question beyond having a product available? It is looking for traction or proving it works at all? Are you creating a new market or trying to steal share from what you perceive to be an incumbent? Do bear in mind that internal technology proofs of concept should be a whole different process to consider.
How will you prove it? The MVP must lend itself to scrutiny through data. What will you collect, how will you collect and validate it? What should the MVP contain as a minimum to help see the impact it is having. A simple idea is finding the time for in-app feedback or a live chat customer support. Miss out something like this and you could be a little blind.
Do we have to build so much? What is the minimum plan we can create? We would like to make technology decisions as late as possible when we know more, so we want to ‘borrow, buy or avoid’ anything not core to the MVP. But do remember the ‘viable’ part of the MVP. The slice of service or product we are creating is to be the best we can create to showcase our intentions and brand in the widest definition. Better to have one or two end to end features that work perfectly, than a whole bunch of half-baked idea thrown in to a rushed app with a nice logo and branding.
In some research around this subject I found a repeated theme that resonated. I have seen many MVPs focus on features — perhaps a rush to get the whole story out there. Rather than a feature focus the aim is a good representation of features AND design AND usability AND reliability AND accuracy. As above I think this leans well towards ‘one feature, delivered really well’.
You could argue that the MVP is a natural step due to the resource constraints of the early enterprise and a need to impress and prove early. But choosing what to build and how is the judgement that only the fledgling startup can define in each case. What I have seen is the challenges created (problems!) in not producing the longer term view. This is one of the factors that will lead to re-factoring, re-architecting or plain re-building services not long after the MVP and investment which is not only wasteful but also demands more resources to build what you already have again in a new format at exactly the time your new investor(s) are scrutinising for accelerated growth. This demonstrates that if you believe in the MVP approach, make sure you design its scope with respect to a much wider perspective- otherwise you risk building a platform that only suits the MVP and is otherwise critically limited.
The clever lead developer, solution architect and/or CTO, as an example, will design for the future but build for today. They will attempt to lay foundations that stand the test of time, whilst investing only in the parts required today. This might be the choice of cloud services, the choice of development language(s) and the frameworks to use. The focus being as much on choosing the right options as it is on avoiding dead ends or expensive mistakes.
This exercise of designing and building your MVP is more than just the technology, and should extend to every part of the business. Many years ago, when working on a global newsstand application we looked at the complications of how to automate the layout of articles and images in a range of magazines that we wanted to digitise as part of the service that would launch across multiple devices. In this case we decided to leave that automation for later. Following a common principle that ‘in order to automate you should first perfect the operation manually’ we asked off-shore providers to create the markup, assets and layout manually for a per page fee. A perfectly acceptable and scalable solution for launch, with an ability to grow with us at least for the first 12 months. We concentrated our resources on what we had to build, bought other ‘parts’ off the shelf (I.e syndicated auth) and used manual operations for complexities we would like to master when we wanted to.
You will note that much of what I consider to be the first principles of start-up and scale-up are related to the principles of Lean Software Development. Some excellent books are available that I won’t compete with here — see Amazon, or better your local bookshop. In this case the MVP attempts to eliminate waste by taking a short cut to only what we need and seeks to amplify learning through the very approach of getting something meaningful to market as early as possible.
Quite a set of balances and trade-offs — but arguably one of the most exciting parts of any new venture — your first release. Remember to take some screenshots as it is all uphill from here.
