Background and the Three Core Inputs
I’ve watched e lean startup movement gain momentum with great interest over the last few years. While I was no longer in a start up environment, I found that Steve Blank’s Customer Development Process worked well for any new venture (new product, new market, or other significant shift of expansion of a component of your business model). While the MVP concept was well documented, I found an alarming lack of focus in the nuts and bolts of product management in this environment. Most descriptions of the customer development process juxtapose it to agile development, so it is interesting to me that more attention is not paid to the meshing of the gears between the two. While not a thorough treatment, I thought I would document the inputs into my backlog.
The Customer Development Process
The customer development process is, of course, the primary (almost exclusive) driver for functional requirements into my backlog. The lion’s share comes from MVP definition, where the business case is driven by the implementation of my business model. I have been heavily influenced by Dean Leffingwell’s excellent work on his Big Picture Agile work. As such, I use a three tier model for requirements tracking (epics, features, and stories). My epics correspond, generally, to the large scale solution assumptions in my business model. I also have epics for major funnels that I am building (activation, revenue, and referral especially). Each epic has a few features which represent the course grain features required. The features are typically sized at a granularity where anyone can understand them and their value. Each feature will have a number of stories, each one at the smallest granularity that delivers business value. While that sounds like a lot of complexity, I will add to the “lean doesn’t mean
The second source of backlog stories comes from testing and refinement. Every day reveals more A/B test results, validated learnings, and assumptions disproven. With each of these, stories get added to make small tweaks and implement new tests to quickly iterate towards product/market fit. Occasionally, a new epic gets injected to represent a pivot in business model.
Organic Architecture
Many seem to gloss over architecture in their quest for simplicity and speed. I’ve found three critical areas that require explicit management of your architecture. The first source of stories is architectural spikes. When delving into the unknown, your technical team will still often need to try something out in order to find the right technical path. The second is architectural runway. Even in the leanest of organizations, there is often a need to set up a database, incorporate a new open source package, or otherwise fortify the underpinnings of the application. I have found that more spikes occur early, and more runway stories occur after some traction has been secured. Lastly, and most overlooked is technical debt reduction. While beyond the scope of this discussion, it is critical that the amount of technical debt that in incurred be managed explicitly. When it gets too high, it needs to get paid down.
DevOps
The guys in operations always draw the short stick when it comes to having a voice in product. Running a DevOps process keeps operations close to the product, and more importantly keeps product management cognizant of the issues that need to be resolved. There are two DevOps inputs that stand out. The first is the output of monitoring (logs, environment, user behavior, and funnels) that indicate an operational issue is occurring. The second is the output of DevOps retrospectives (five why meetings or equivalent). One of the most insidious forms of technical debt is Operational Debt and is characterized by manual processes in operations that lead to outages, execution/scale constraints, and budget overruns.
Putting it all Together
A good product owner or team can take these inputs, weave them together and avoid many of the classic pitfalls of a new product.
