in Agile, Startups

Agile is the ‘Build’ in Lean Startup

After writing a few answers on Quora about how teams develop software over the maturity of their product, I noticed that I kept mentioning to focus on two separate things.

  • Agile methods for managing the throughput of work… for mature teams that are looking to optimize
  • Lean Startup to help teams find what to build… for new teams building the first version of their product.

Turns out I was wrong… kind of.

As with most things, a healthy mix of both seems to be the best solution.

First things first, so what’s the Lean Startup?

LeanStartup

The Lean Startup is a methodology based on a repeating, three-staged process:

  • Build
  • Measure
  • Learn

The aim is to shorten your time in each loop. By doing this, you increase the amount of customer feedback being sent to your team. This feedback allows teams to make more informed product decisions, earlier on.

It’s experimental and does away with making assumptions.

It just makes sense, right?

Agile software development is ‘build focused’

Nowadays, the way teams usually ‘build’ their software is using an agile framework or methodology (most likely in the form of Scrum or Kanban).

If you start with one if these on their own, you’ll quickly find you’re developing features out of a backlog that’s an “everything bucket”.

trash

That’s because most of these frameworks simply assume that there is a ‘backlog’ which already exists.

Don’t assume you know what your customers need

If product management isn’t your team’s thing, your backlog will probably end up being a mix of:

  • All of your team’s ideas
  • One team member’s vision of the product
  • Features your customers are shouting loudest about

Unfortunately, it probably won’t have a blend of what a great product roadmap has. That is:

  • Your product vision
  • Customer pain points
  • Customers’ jobs-to-be-done
  • Customer requests which build long-term value

customerfit

Don’t forget, these will still be assumptions. Albeit, well-informed ones.

It’s all about product/market fit

“Fall in love with the problem not the solution” — Uri Levine, co-founder of Waze

With a stellar product roadmap in hand and backlog of tasks to work off. It’s time to build, test and validate your ideas.

But first, let’s get back to the basics…

Fundamentally, teams build products to meet the needs of a market. Both change rapidly.

As such, teams should be on a constant pursuit of product/market fit.

three-startup-steps2

Get through the loop quicker with an MVP, then MFFs

Create and iterate upon an minimum viable product (MVP) to validate your product fits a market. An MVP is:

“[the] version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort” — Eric Ries

mvp

From then on in, build out the minimal marketable features (MMFs) you identify in your product roadmap. In other words, build features in a way that:

“software is developed and delivered in carefully prioritized chunks of customer valued functionality

For each MMF, develop just enough to test whether your customers will use the feature. This could mean:

  • Creating a ‘feature button’ which says ‘coming soon’ when clicked
  • Building the most bare-bones version of the feature
  • Blogging about the feature to measure engagement
  • and, so on.

Once you’ve built measured and learnt from the feature, either iterate it or pivot to another feature.

It really is that easy.

Although you probably have one last question… how do I decide what my MMFs are in the first place?

How do I decide what to build?

Job stories are based on the jobs-to-be-done framework.

In a nutshell, they focus on the ‘why’ and are what you should base your next features on.

job-story

Define your customers’ job stories and document them in your product roadmap so they can be worked on by your product team.

In contrast, a user stories define solutions for how a job story can be fulfilled. That is, a customer’s problems (“the why”) can be solved in multiple ways (“the what & hows”).

job-story-solved

Rinse and repeat

Continue to build, measure and learn every-single-day.

And most importantly, never assume.