How a Business Analyst can Support a Lean Startup

This week I completed reading The Lean Startup by Eric Ries.  Without a doubt, this book is a must read for all entrepreneurs and business leaders.  The real gem of this book is Eric Ries’ formula for launching a startup: build → measure → learn, which he calls the “feedback loop.”

Ries details each aspect of the feedback loop, but it is clear that “learn” is the key variable of the formula. According to The Lean Startup methodology:

“learning is the essential unit of progress for startups. Any effort that is not absolutely necessary for learning what customers want, can be eliminated.”

With that in mind, Ries goes on to explain that in order to know what efforts will lead to learning and what efforts should be eliminated; startups must form a series of hypotheses.  These hypotheses should serve as the foundation for what’s needed to learn and specifically attempt to answer:

1) How the startup will grow and

2) What value it will provide to customers

These hypotheses are the bread and butter of the feedback loop.  With them, startups can then define what aspects of their business must be measured in order to validate the hypotheses.

By linking business metrics to the startup’s value and growth hypotheses, a startup can then eliminate what Eric Ries calls vanity metrics (metrics that look good in a press release but really don’t mean anything to the value or growth of your business).  Eric Ries defines these hypotheses based metrics as “innovation accounting” metrics.

So what does all of this have to do with the role of a Business Analyst (BA)?

Typically, a BA’s role on a team starts with the process of requirements elicitation and ends with the creation of a product requirement spec detailing what features will be built for the next release.

To that end, Eric Ries states that

“we write the feedback loop as Build-Measure-Learn because the activities happen in that order, our planning really works in the reverse order: we figure out what we need to learn, use innovation accounting to figure out what we need to measure to know if we are gaining validated learning, and then figure out what product we need to build to run that experiment and get that measurement.”

This is exactly where the BA can support a Lean Startup, since learning as a first step is exactly what the requirements elicitation process is all about.

This is why the skill set of a BA fits perfectly with the reverse build →measure → learn planning process.  In my role as a BA over the years, one of the main skills I have developed is the ability to elicit requirements in the context of a pre-defined scope.

When you are in a room of diverse stakeholders tasked with defining the requirements for an upcoming release, you learn the art of facilitation that requires taking “nice to have features” and putting them of the proverbial “parking lot” while at the same time driving the conversation to focus on those critical features that will make or break the release without making anyone feel marginalized.

This art of facilitation is exactly what I believe would be invaluable to a Lean Startup.

The business analyst in a lean startup should be the chief adjudicator of product features using Eric Ries’ concept of “innovation accounting” as the foundation for defining the scope.

As such, the principal BA skill that must be utilized more than any other is this ability to facilitate and adjudicate the iterative development of product requirements using the elicitation process, and then tracking each requirement using an “innovation accounting” requirements traceability matrix that:

  • maps each requirement to the value and/or growth hypotheses
  • identifies which requirements will provide measurements for validated learning as well as define the measurement
  • prioritizes requirements based on the direct impact on the primary engine of growth

In a perfect world every startup would have a dedicated BA.  However, I understand that it makes sense in most startups for the BA to double or triple up as the product manager and/or project manager.

In either case, I believe having a single owner of an “innovation accounting” requirement traceability matrix managed using the fundamentals of business analysis provides three benefits:

  1. a  higher quality product road map
  2. a tool to help developers build the product right
  3. an objective analysis for managers to measure if they are building the right product