Let's Create a SaaS Startup 2 - Minimum Viable Product

17 August 2017

How not to build software

I’ve been creating client software projects for a number of years now and have learnt how not to create a software project the hard way.

Over and over and over.

Through the years I’ve learnt that not treating the process of building software as the serious topic it is, you’ll:

So, what’s the standard way of creating a software project?

But fear not! There is a much better way to approach any software project and we’ll discuss that more in a moment. In this article we’ll discuss a smart way of thinking about any new software project and also a little about controlling project scope if you’re creating a minimum viable product.

Getting serious!

How not to build a minimum viable product

In startup-land, a minimum viable product (MVP from now on) is an early representation of your product that delivers value in some way to your potential customer. This allows you to test your nugget of value with your customer base and learn if you’re on the right track.

There are many other interpretations of what an MVP could be, such as a landing page, demo video or sales interview, but for the sake of this post let’s assume that a good MVP creates some sort of customer value.

The primary goal of an MVP is to deliver customer value and determine customer interest as quickly and efficiently as possible, avoiding 6-12 month build times for an audience that might not care for your product.

An MVP needs absolute purpose and laser focus.

An MVP should be embarrassingly small (but still provide customer value).

An MVP is a step in the learning process.

When thinking about this version of your product, you should be cutting features relentlessly to find the golden nugget of value that you’re providing to your customer base. Your unique value proposition.

Only build the thing that provides that. Everything else can wait.

What you include in your MVP will be the natural outcome of setting clear goals and priorities for your project which is what we’ll discuss now.s

There are two clear stages that I like to use when creating any new software project, so let’s get into them!

1. The Foundational Stage

Thinking about the foundational goal

When creating a product (for ourselves or a client), it’s important to have a driving force behind every decision we make, to create a foundation of clarity.

In the case of my first SaaS product, the foundational goal emerges as the result of my earlier research, my Sales Safari.

For client work, the foundational goal should emerge from your initial call or discovery sessions.

The foundational goal of the product should be short and to the point. Here’s the foundational goal for Drum (that’s its name!), my first SaaS product:

Drum foundational goal

Is it broad? Yep.

Is it a bit “woo-woo”? Yep.

Is it impossible? Probably, yes.

Does it give me an overall feeling of what I’m trying to achieve for my customers and users?


This is the foundational driver of the project, providing a guiding light for every step forward from this point onwards.

I want my customers to literally sigh a breath of relief when the start using Drum and I think this is a good summary of how I can achieve that.

Thinking about who we’re serving and their jobs-to-be-done

I love the jobs-to-be-done framework! You should too!

It’s an incredible way to think about what your users really need and want to achieve in their lives and creates a great overview when thinking about product (and business) design.

Let’s use the client and project manager or freelancer relationship to think about the jobs-to-be-done for Drum (If you’re working along to this as well, take a moment to think about your users jobs-to-be-done in your word processor of choice).

Some jobs of the project manager (PM) that involve their clients could be:

Here are some jobs to be done for the client when working with the PM:

What an incredible (yet incomplete) overview of our customers!

This is an absolute treasure trove of information that we can work with and build from. Let’s think about how these stakeholders are currently working through these jobs in a broad sense.

What are the current solutions that they’re using to achieve these jobs?

There are no doubt more current solutions that are being used, but at least now we have great vision on what our customers are currently using to achieve their jobs.

Now, each job can and should be broken down into the functional and emotional aspects as per this overview on jobs-to-be-done, but let’s just focus on just one for the sake of this post.

PM Job: Contact Client For Project Updates

The functional aspects could be:

The emotional aspects could be:

Can you see how thinking about user’s jobs to be done can now impact how we think about the features and design (not just visual) of our application?

With whatever product we build, we want to:

By understanding our users and how they currently complete their jobs, we understand how to make their life better and provide excellent value with whatever product we decide to create.

Let’s get specific with project goals

Let’s take a step back for the moment. Now we:

Now it’s time to get specific with what we want our application to achieve for our users. These are still not traditional SMART goals but are important to understand as we move forward.

With this round of project goals, we want to define what we want to achieve in our MVP based on our customer research, foundational goal and our users jobs-to-be-done.

In fact, it’s the perfect opportunity for a big old fashioned brain dump.

Dump down all of the goals that you’d like to achieve with your MVP. They should be impossible and ridiculous and everything in-between.

Just get everything down. No filter.

Your job is to choose three goals that you want to achieve with your minimum viable project. Base them off the research you’ve done up until this point and make them count!

The project goals for Drum are:

  1. Let users get in and out as quickly as possible. Efficiency at every step with no redundant clicks.
  2. Users should know exactly what is happening in their project at all times.
  3. Project communication and feedback faster and more impactful than e-mail.

Simple, right?

Everything we’ve done leading up to this point now sets us up for the very practical stage for our project planning.

2. The Practical Stage

Deciding what to build

Its time for brain dump number 2 (don’t be gross).

The foundation for our product has been set and it’s time for you to think of every possible feature that could be created to meet our goals.

Once you’ve exhausted your brain’s ability to create new features, no matter how outlandish, it’s time to filter those bad boys.

  1. Which of the features that you’ve listed fails to achieve the jobs-to-be-done or goal alignment?
  2. Which of the features meets our requirements, but does it poorly?
  3. Which of the features can you create easily that are also high impact?
  4. Which of the features can you create with some difficulty that are high impact?
  5. Which of the features can you create easily that are low impact?

All of these questions will naturally filter your requirements to those that are both goal-aligned and high impact. It’s also important that you minimise the difficult to implement features that are also high impact, simply for the sake of shipping your product in a reasonable time.

Using a modern web software tech stack, you want to filter your list to something that you can build in 2 months or less for your MVP. In a perfect world, it’d be even shorter than that (and it will be if you can refine your feature list to only a couple which are both goal aligned and high impact).

My goal with Drum is to be able to create it for initial customer testing within a single month.

Creating user stories

Now its time to transform your feature list into something much easier for you to work with, user stories.

User stories follow the template of:

As a **, I can ** so that I can **.

Generally speaking, it’s something that should be quite simple to create from the feature list you’ve created above.

Why transform your feature list into a series of user stories?

In Drum I’ll have two primary user types; clients and project managers. I need to know which feature is for which user type and why.

Here are some user stories for Drum chosen at random:

If all goes well, you’ll notice a natural alignment of your user stories with your customers jobs-to-be-done. Nice work.

Project Specification

For your personal projects, you probably don’t need to take this step, so feel free to skip ahead.

With client projects, this is the perfect time to create the final project specification, with all of the steps leading up to and including this point being part of a discovery or road-mapping engagement.

Luckily for you, you’ve done everything you need to create a fantastic project specification for your client at this point and it’s just a matter of melding your work into a specifications and/or project proposal.

I’ll chat more about how to write a great proposal and project specification in another article down the road.

Creating Project Time Constraints

Armed with your feature list and user stories, you can now set a pragmatic due date for your project.

No seriously, set a due date right now.

A project with no finish date will continue for eternity which is not what you want when you’re trying to get your product in front of customers as soon as possible.

So you have a due date and a bundle of user stories, now it’s time to plan your success week by week. Here’s what to do:

What Now?

Now you know how to think about creating your project, it’s simply time to create it! In the next article in the series, I’ll talk about how I think about the user journey in a software project and also my thoughts around user experience and interface design.

After that article, we’ll talk tech and why your tech stack isn’t as important as you think.

These are some of the tactics I use when working on my own client or personal projects, but there are many ways to approach software and product development! This is by no means meant to be the best way to build a thing, but hopefully it’ll create clarity for you in your next project or help you out if you’re looking to build your minimum viable product.

Until next time!


p.s. If you’d like to learn more about using the jobs-to-be-done process for creating innovative products, please check out this interview with Karen Dillon on thisisproductmanagement.com: Jobs to be done interview