How to Manage a Successful Lean MVP Project

In ancient days, software development was modeled after manufacturing. Projects were organized around a giant, monolithic specification document, called a Spec.

Project managers would spend months (or longer) putting together a spec document—mapping out and planning every single function and operation of the software, down to the tiniest detail. Then the spec would be given to the engineers, who would implement it.

At every step of the way a spec had dependencies: Step A had to be finished before engineers could start on Step B, and so on. This was called a “waterfall”, because the resulting product management graphs resembled a waterfall. The process was costly, complicated, prone to delays, and resulted in systems that were complex and required special training to use.

Of course, if you look at the history of computers, this approach made sense: the first computers weren’t much more than giant analog calculators. Every circuit had to be planned out in advance and carefully manufactured to spec in order for the machine to work properly.

But as computers evolved, so has software development.

We no longer make computers out of wires and vacuum tubes, and the computer in your pocket or on your wrist can do things that even the creators of Star Trek couldn’t imagine.

We no longer have to rely on waterfall charts or spec documents to create software. Almost all software today (especially web and mobile products) are developed using a different set of methodologies that we call Agile.

How we apply agile principles to launch new projects efficiently

“Agile” is a set of project management practices that, simply put, aim to reduce waste. By waste, we mean wasted time, wasted effort, and wasted resources. We reduce wasted time by not having engineers waiting on one another. We reduce wasted effort by responding quickly to change rather than doggedly sticking to predefined specs.

Stories, Epics, and Milestones. 

Where waterfall spec documents are complex lists of requirements, each one dependent on the previous, Stories are a much more generalized definition of what the project must accomplish in order to be considered a success.

A story is just a short statement of what should happen in the app. For example: “a user should be able to enter a username and password to login” is a story.

Stories, in turn, are organized into epics. An epic is a group of stories around a discrete feature. For example, an epic might be: “Voting on cat pictures”. Stories inside this epic might be:

• A user can upload cat pictures.
• The system should validate that uploaded picture is really a cat.
• Users should be able to vote up or down on each cat picture.

Finally, epics are organized into milestones. A milestone is a group of epics (features) with a deadline.

The Plan > Code > Learn Cycle

The first step of the planning process is to decide what success looks like for this project.

Is the project an internal app that will make your business run more efficiently? Is it a line of business app that will bring in new revenue for your business? Is the app the core business of your startup?

Defining what success looks like helps us to know what to focus on. Without the perspective of success it would be easy to focus on the wrong things. Knowing the outcome that we expect helps us to decide what features to build, and which ones to build first.

The next step is to outline the features that we’ll be building. There may be a long list of features that we’d eventually like to build into the app, but we’ll whittle this down to a very short list of just a few features that will contribute to the initial success of the app.

Then we’ll organize these features into stories, epics, and milestones.

At this stage we’re almost ready to get started coding, but not quite: there’s still one thing left to do. We need to define success for each step of the development process.

Each step of the process is called a Sprint. A sprint is like a mini-project. It is a short period of intense work, kicked off by a planning meeting and followed by a review meeting.

Before we start each sprint we decide what success will look like for that sprint. We’ll set out one or two measurable goals for this sprint. How does the work that we are about to do advance the overall goal of the project? What are some data that we can gather to know whether or not we met our goals for the sprint?

Learning

This is where we begin to realize the value of the iterative approach.

What can be done with learning?

Learning is the true value of iterative MVP development.

Obviously we don’t mean that you need to be educated about your product. You are your product’s number one expert.

When we talk about learning, we’re talking about a scientific approach to launching a new product. That means making assumptions and then testing those assumptions.

After each sprint, we take a step back and try to identify what we can learn from that sprint. What happened during the sprint? Did we accomplish the goal for that sprint?

Let’s say, for example, that the goal for the sprint was to complete a feature that allowed users to vote on cat photos. We completed the feature and launched it to our beta users.

There are several data points that we could look at: total number of votes, number of users voting, how often users voted, how long they spent looking at cat pictures. Many of these data points will be instructive, but we’ll try to drill into just one data point that we can learn from.

In this example, since our goal is to build an app with a strong viral component, we decide to focus on how many votes each user cast. That metric is the most informative because it tells us: how long a user spent looking at cat photos and how many photos they’re looking at. It also tells us if particular users are having trouble; we can follow up with any users with no votes to find out why they aren’t using the feature. And since other uses get notifications whenever someone votes on their cat photo, there’s a strong viral component to get users coming back to the site to see which cat pictures are the most popular.

Equipped with this data, we are now able to make a smarter decision about what to focus on next. Maybe we decide that it’s worth spending some time refining the voting feature to make it really smooth. Or maybe we’re happy with the feature and it’s time to work on the next new feature.

At each step of the process, we don’t just forge ahead and build the next thing on the list. Instead, we collect data, discover what we can from that data, and then apply our learning to the next sprint.

Putting You in the Driver’s Seat

At The Small Idea Company we have a little different approach to managing your iterative building process: we treat each sprint like a separate project.

Most development firms nowadays follow some variation of iterative or “agile” development, like what I described above.

But we take it a step further. Rather than treating your project like a big, multi-month project, we break your project down into discrete sub-projects. Each sprint is treated like a mini-project. At the beginning of each sprint we meet with you to plan the sprint, then we do the work, then we meet with you again to show you what we did, and finally we have a mini-launch. We’ll deploy the project and hand it off to you.

This has several advantages:

• You are in control of your spending.
• You can control the velocity of your project.
• You are involved in the ongoing product design process.
• You have multiple opportunities to learn along the way.