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:

• Invite project scope creep at every opportunity.
• Encourage miscommunication between client and creator.
• Find it difficult to plan a project.
• And struggle with cash flow because of the above!

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

• You (or a client) has an idea.
• You roughly outline what the idea entails.
• You build based on the outline.
• You experience the negatives outlined above throughout the project and feel bad.

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.

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:

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?

Yep!

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:

• Investigate client needs for successful project.
• Create project documents for clear scope and specifications.
• Create legal documents for the project.
• Contact client for project updates.
• Contact client for project milestone sign-off.
• Liaise with client for design and general project decisions.
• Implement feedback items and bug fixes received from the client.
• Liaise with client for project completion and sign-off.

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

• Communicate scope of works and project goals to the PM.
• Accept project specifications for the project.
• Approve contract for the project.
• Provide feedback on project deliverables.
• Approve partial deliverables for the project.
• Written approval of significant project milestones.
• Provide bug reports for project features.
• Sign-off project completion and deliverables.

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?

• Email (for nearly everything)
• Phone calls for scoping the work, providing feedback, agreeing on milestones.
• Internal project management tools for bug reports, feedback (Trello, Basecamp, Asana etc).
• Excel, Numbers or Google Sheets for bug reports, feedback.
• Potentially Github or Bitbucket for bug reporting (if the client is technically inclined).

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 client needs to be informed in order to provide feedback or approval.
• There was an agreement in the contract that the client be informed of progress every two weeks.
• The client must be informed and provide approval for the project to continue.

The emotional aspects could be:

• The client should feel informed at all times so that they trust my services and will want to work with me in the future.
• I want the client to feel like we’re making consistent progress on their project.
• This is a fantastic opportunity to demonstrate our great work for the client.
• I feel good that I’ve delivered more functionality at a high standard.
• This is an important milestone in this project.
• I’m ahead of schedule on this project and my boss (and client) will be happy.

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:

• Encourage our users to feel the positive emotions from their jobs.
• Enable our users to achieve the functional aspects of the jobs as efficiently and obviously as possible.
• Respect their existing tools and methods and nestle into their existing workflow in a way that compliments the whole process.

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:

• Have a guiding light for our project with our foundational goal.
• Have identified our user base (this happens before you start thinking of product).
• Understand the jobs that our users are already doing and the emotional impacts of each of those jobs.

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.

• What is the feature?
• How does it work?
• How does it meet our goals?
• How does it align with our user’s jobs-to-be-done?

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?

• They lend themselves very well to automated acceptance tests during your development process (you write tests, right?).
• They break your project into small, manageable chunks.
• You create clarity around who is feature is for and how it fits into the larger picture.

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:

• As a project client, I can comment on a task to communicate with the PM.
• As a project client, I can sign-off on a project milestone to progress the project and create a clear project timeline and paper trail.

• As a project client I can view project documents so I have a single source of truth for project resources (no digging through email, yay!)

• As a project manager I can create a new project so that I can create a structure for the project with my client.
• As a project manager I can upload project documents so that documents are easily accessible for the client and myself.
• As a project manager I can mark a project task as complete so that the client knows how their project is progressing.
• As a project manager I can mark a project task that requires client sign-off as complete so that the client is notified of a milestone and the need to take action.

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:

• Determine how many weeks you have to ship your product.
• Allocate your user stories that you think you can reasonably achieve on a week by week basis (make sure it’s reasonable, nothing will kill your motivation like not hitting your goals week after week).
• Kick ass and take names as you knock out features week by week.

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!

Ben

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