Software development methodologies like Agile (a broad philosophy) or the manufacturing-influenced Lean (a more narrow approach) are primarily mindsets, but at their core is the Scientific Method. Both point to the need to identify our assumptions, craft a hypothesis, test said hypothesis, and then learn from that.

This is often referred to as the build-measure-learn feedback loop.

We begin with a hypothesis: we believe there is sufficient demand by a very specific cohort of supporters of Central City Opera to stay connected to the company in a meaningful way after their contract period ends. We believe that a web-based effort modeled in part on a traditional university alumni association is the best solution to this problem.

Identifying Assumptions

Put another way, let’s run this classical exercise in identifying assumptions from a fantastic Product Management Course I took this past summer:

“I assume that ____________ matters to my users, who are _________. My users have the problem of ___________. Users will pay for / sign up for it. There are no satisfactory substitutes.”

So, for our purposes:

“I assume that keeping a meaningful connection to Central City Opera beyond the end of their contract matters to my users, who are company alumni. My users have the problem of wanting to help, but not knowing how to help, and donating money is often not an option. Users will sign up for it. There are no satisfactory substitutes.”

The above is one super basic version of a hypothesis often formulated for the purposes of building and testing an MVP. There are other, more elaborate (and likely more meaningful or more accurate) versions which we can and may explore, but you get the idea.

The MVP

The MVP, or Minimum Viable Product, is Agile Development’s actionable expression of the Scientific Method. It is both an actual, functioning software product (not just a prototype), and also an experiment. After identifying your assumptions, focusing on the one assumption you want to validate first, you then craft a hypothesis — which for our purposes is an actionable statement.

For the purposes of this project, the MVP will be a website. This is the build part of the build-measure-learn feedback loop.

So, a simple, fill-in-the-blank hypothesis might be:

“We believe [subject/target] will [predicted action] because [reason].”

For our project, we might complete the above as follows:

“We believe Central City Opera Alumni will visit centralcityalumni.org, sign up for a newsletter, and answer calls to contribute ideas, time, and perhaps eventually money because there is an unfilled need for them to remain connected with the company beyond the end of their contract.”

The short version of what comes next is in the aforementioned feedback loop is that we measure and we learn. For a project like this, measurements will come in the form of response rate to the survey we’ll be putting out in October 2019 as well as sign-ups in whatever capacity we’ll engineer them for the MVP come Spring of 2020.