When was the last time you did a Minimal Viable Product that was actually minimal? How often do we get it right and truly focus on delivering something of value to the customer?

On this week's podcast, I riff on the idea of how to get a true MVP, not only past the idea stage, but into production no matter what type of company you are. By looking at the constraints that we have in play at any one time, we can determine before we get started with an MVP how it might be rolled out.

We also touch on the importance of marketing for your MVP and/or product – and ensuring that you have a customer base that wants it before you get there. How you can even use your compliance journey to road-test your idea.

Join me for this discussion and, as always, let me know your thoughts about what’s gone wrong and what's gone right with your MVPs!

SHOW NOTES

This show inspired by some systems thinking, some writing and also the theory of constraints.

https://richardwbown.com/how-the-mvp-has-lost-its-meaning/

https://en.wikipedia.org/wiki/Theory_of_constraints

https://richardwbown.com/approvals-come-first/

QUOTES

00:49: “Much is made of the MVP, the minimal viable product. But so rarely is it executed in a meaningful and valuable way.”

02:02: “Using an MVP to road-test new tech is not always a smart move.”

03:19: “architecture just means big decisions that you're probably not going to undo later.”

03:59: “There is a tension here between architecture and MVP”

06:35 - “By narrowing our proposal for our MVP. We stand a greater chance of getting it approved and rolled out in order to gather feedback”

07:28: “The reasoning behind the processes that build up around change control are all there for sensible reasons.”

08:15: “Whatever of path is open to you, your MVP won't deliver unless it has users”

08:49: “Don't leave the marketing to last or as an afterthought. And this applies not just to startups or individuals, but also to the scale-up or corporate world”

Welcome to the software delivery club.

Every two weeks.

I explore different aspects of the business of delivering software products.

Talking with industry experts about subjects that are crucial to building

and delivering amazing software.

We discuss customer needs, how products change and how changes get delivered.

We also talk about keeping on top of our technological and engineering challenges.

We talk about tools, both theoretical and practical.

The ones that we like to use to improve our software products.

As well as tales from the front line, all about delivering and

supporting production grade software.

Thanks for joining me.

My name is Richard Bown.

This is episode 16.

All about the often heard and rarely delivered minimal viable product.

I wrote about this recently and it resonated with lots of my readers.

So I wanted to dive into the subject a bit more.

Much is made of the MVP, the minimal viable product.

But so rarely is it executed in a meaningful and valuable way.

When I wrote about it, I gave it a quick rundown as follows.

Take an idea form it quickly and work closely with the developer.

A designer and a marketer to realize it as soon as possible.

All this sounds simple enough, but how hard this is, and reality all

depend on your company circumstances and how fast you can move.

If you're a small, independent company, a non-corporate then perhaps

there are low barriers to entry.

You have your platform.

Your technology stack perhaps already decided, or you can pick up

a new one and play around with it.

You are free to experiment.

This can be nice from some perspectives because your MVP

then also becomes a playground for new ways of achieving things.

However, this can also be to the detriment of the initial intention.

Too many choices can mean you're confused as to what you want to accomplish.

If you want to focus purely on the product and be able to deliver

functionality quickly than being distracted by a new technology

may take away some of your focus.

Ask yourself if the new technology is an enabler of this MVP, or

if you can accomplish it using technology with which you're already

familiar and comfortable with.

Using an MVP to road-test new tech is not always a smart move.

You might have also come across some formalization of the

prototype phase of a project.

This was often taught in the pre-Agile, pre Lean model of

the software development world.

A prototype could be built quickly and cheaply.

But it was only there as a proof of concept and it should then

always be thrown away completely after you've done with it.

This can work effectively.

Especially as a mental model for keeping your prototype down to a

reasonable size or amounts of effort.

However, the key difference between a prototype and an MVP

is that the MVP is actually meant to exist for the user to try out.

It's intended as a product.

Albeit a thin or incomplete one.

In practice, the prototype often ended up as a sort of unintentional MVP anyway.

Many prototypes became final products.

And I guess this is why the MVP became quite popular.

Because we all know as engineers, that the first thing you build will be the

thing that persists . The first thing that is popular and actually makes a

difference to your user, will stay.

And this will then mean the architecture of the thing you're building

will be based on your prototype.

Architecture can be a problematic word here.

In this case for me, architecture just means big decisions that you're

probably not going to undo later.

Usually the big decisions we make as product designers or

software engineers are around what technology we're going to implement.

While we would like to be abstract in our thinking.

That comes a point when the reality of the supporting technology

has to come into our thoughts.

So technology choice is important because it's going to stick

with you if your MVP works.

However learning a new technology may be best suited to re-engineering

or re-factoring exercise.

Or if you're clever with your architecture, maybe you won't

have to worry about this.

You can drop in a new tech as you see fit.

There is a tension here between architecture and MVP.

You can't run ahead and architect because you don't really know

where you're going when you start.

You want that freedom to express your perceived customer needs in

whatever way you feel is best.

To back up for a second, that's one extreme.

When you're a startup or just starting out with a new project as a soloist

and you have all the choice it's mainly shaped by your preference.

But let's look at the other side of things where you already have some technology

stacks defined either by you or for you.

You may have to play by the rules and regulations of your company

or your auditor or whatever you see is as a constraint or

the man figure in your world.

The one who's setting the rules or the rules of the game that you must play if

you want to deliver your software product.

In this case, according to the theory of constraints.

You could propose your change to the most constraining part of your service.

You could align the majority of your efforts to make sure that

this is signed off before you even start work on your MVP.

So how could this look?

For example, imagine that you're a developer working in a bank and you have

an idea for an application that will tell us exactly how much energy your

computer is using at this moment in time.

It's not really possible for us to know.

But, let's just say you can estimate how much energy is being

used by your computer, by the software that is running on it.

You think that this will be a great thing for the bank's customers.

It could be given away to them to help them limit their energy use, to save

them money and to show how much your bank is thinking about the environment.

So you have a great idea and you'd like to get approval for an MVP that you could

deploy on the banks devices, to other members of staff and get an idea how

it would work and gather some feedback.

You've already cleverly developed this piece of software so they can work on

every single device in your organization.

From mobiles to laptops, to data center, to cloud instances.

And even switches and IOT devices.

It's lightweight, deployable anywhere.

Your constraint here is that for each of these platforms, there will be rules.

There'll be separate approval processes and different people

involved in their approval.

For example, the mobile device organization will sit in a

completely different reporting and approval line to the data center.

If you want to do this on a cloud instance, you'll need to find all of

the various groups that are using them.

So you've got a potentially great solution but perhaps your reach

is too big in this first instance.

Are you trying to accomplish too much?

If we get back to the original mission to give this to our customers.

Perhaps we can just focus on one device type to begin with, say mobile.

And then perhaps we can narrow it down to just Android.

If that's easier.

And then perhaps we can identify a single group of Android users

in a friendly part of the company.

By narrowing our proposal for our MVP, we stand a greater chance

of getting it approved and rolled out in order to gather feedback.

Also, we reduce the amount of administration we need to do.

If you have rules in the workplace about infrastructure, about coding

standards, about security baselining then you're always going to struggle to

make a product as minimal as you'd like.

But perhaps your environment has thought about that and you can

use something like a paved road, a landing zone for your application.

Then perhaps you're need to understand all of the other parts is reduced.

Some of the work in your MVP becomes an investigation.

How you can best accomplish what is closest to your original mission without

getting too distracted by these pieces.

This same discipline, thinking about the constraints we have in

our systems as a corporate, is a great thought experiment we can also

do if we have fewer constraints on what we can do in a startup world.

The reasoning behind the processes that build up around change control

are all there for sensible reasons.

They exist because we as an organization of any size, are scared of making

mistakes with customer data, with new functionality and features.

And we want to have a world where we deploy changes in a controlled

and useful manner, which is above all safe to us and to our users.

Therefore our MVP in either case here has to stick to rules written or unwritten

about how our product will behave and also what it allows us and the users to do.

Yes, ideally these days we have all the freedom in tech,

in functional and design choice.

But when it comes down to it, often group dynamics, supportability, accountability,

audit, compliance, and other factors.

May limit our choices in a practical way.

Whatever of path is open to you, your MVP won't deliver unless it has users.

So along with speed of delivery, you must ensure that you make some noise.

Create a landing page for your app.

Describe what it's going to do.

Get some users signed up to a mailing list.

This applies, whether you're internal or external customer facing product.

The point of an MVP is to prove there is a need for something.

To realize it, you need technology, product design and product marketing.

The commitment of users wanting to use your MVP will drive you forward.

Don't leave the marketing to last or as an afterthought.

And this applies not just to startups or individuals, but also

to the scale-up or corporate world.

Your hard work should be represented to something that is of use to

people in whatever form that takes.

When we write a library or a module that can be reused, provide examples.

Make it easy to integrate.

Put it on platforms where others congregate and are likely to benefit.

Because there's nothing worse than a failure.

Or launch into the sound of nothing.

And again, the engagement of your audience is the point of your piece of software.

Your compliance journey is also engaging an audience.

It's a restricted audience with a certain worldview but that doesn't

necessarily limit them to having opinions solely on whether your MVP

is compliant or not . Use that as an opportunity to also gather more feedback.

Like any creation, releasing an MVP to the world can be a scary thing.

So engaging with your audience before you release it, is

never going to be a bad idea.

To set expectation.

To hopefully not oversell it in the first place, but to have an audience which will

use it and love it and give you feedback.

I'd love to hear your stories about MVPs and how you've got them into

the world and how, when they arrived it differed from your expectations.

Usually we get very different results to what we expect or anticipate.

And that's the whole point.

I hope you've enjoyed this week's episode.

Please check out my newsletter where I explore the subject of

software product delivery every day.

You can sign up by going to software delivery.club.

And you can also reach me on Twitter.

At @richardwbown that's R I C H A R D W B O W N or on LinkedIn or via the website.

Until next time, keep coding, keep dreaming and keep thinking product.