The Dog Food Diet: A Product Ownership Interlude

 

As Dilbert once said (sort of) “Welcome to product management.  Two drink minimum.”  At this point, 6 sprints into the project our release burndown looks something like this:

Screen Shot 2017-12-20 at 6.53.15 PM

Aaaaaaannnnnnyyyyyyyhooo …. 

This release is going to happen, probably sometime around Sprint 10.  There is no question that the product works and the functional release goals will be substantially met.  There are stories that have appeared out of nowhere and gone to the top of the backlog, stories that seemed critical that have fallen to the bottom of the backlog and stories that have failed in execution and had to be reworked from scratch.

Given that this is an internal release there’s little angst that goes into “calling it done”.  The more interesting questions revolve around what comes next.  After this release we’ll have something with a positive ROI when sold to one customer, us.  What about customers who aren’t “us”?

Up to this point we’ve put a small handful of PO stories on the backlog.  Generating lean canvas for the product, maintaining an up-to-date bill of materials to give us an upper-limit unit cost, and some better-than-internal documentation.  Now our PO needs to build a decision about whether or not to sell the product to people who aren’t “us”.

We’ve reached a commercialize-or-not decision for the product.  The team, including the PO, desperately wants to commercialize.  You want them to want this.  “Purpose” is a key part of motivation (Autonomy, Mastery, Purpose) and if your team doesn’t feel they are serving a big, worthwhile purpose then they won’t perform well.  But this means that if the team and PO just sit down and talk about whether or not to commercialize all you’ll hear is various flavors of “Hell yeah!”.  We need metrics.

Because of the company’s unique (alright not-so-unique) position, “time to break-even” and “maximum exposure before break-even” put hard limits on the investment we can make in the product.  A version of the product that takes too long to break even, or takes too much investment to launch at all would require the company to bring in a round of investment, which pushes the decision up a level from the PO/Management Team level where it lives now.  Again, typical constraints.

Getting those metrics done well, and being hard-headed about them is top priority.  What do we need to get those metrics?  For this particular product:

  • Cost of labor to build this.  This should fall out from a well-constructed product backlog and the velocity metrics we’ve already produced.
  • Legal and regulatory.  There are expensive regulations that need to be met to commercialize this, we know what they are, we just need hard numbers and timelines about how to meet them.
  • Cost of go-to-market.  Given a product that meets regulatory and does things people will pay for, what does it cost us to get them to buy enough of it that we reach break-even without breaking our total investment ceiling?

Second priority is the potential return on this investment.  We split this into two questions that will look familiar to fans of Lean Customer Development:

  • Does anyone besides us have the problem this product solves?
  • How many people have this problem and what will they pay to solve it?

Scrum Implications of Commercialization Decision

2drink.pngWhat does all this mean for the team?  In large companies, except for the BOM and people-cost, all this “business stuff” would disappear into a black hole of decision-making populated by business trolls doing exclusively business stuff.  But we’re a small company and we need to do all this with pretty much the same team that’s actually building the product.

We’ll use a typical structure that enables swarming.  Our PO will structure the Lean Customer Development stories, and the team/PO will figure out how to get them done and run them off the same Sprint Backlog that we build the product from.

On top of all that, the team realizes that given the amount of work and sheer calendar time that needs to go into this decision, we’re very late getting started.  Customer development interviews, in particular, eat calendar time.  We’ve already started Sprint 6, with almost exclusively product development stories and won’t want to wait two weeks to start on commercialization stories.  Fortunately, our kaizen from Sprint 5 was to implement the interrupt buffer pattern and we now have 10 points of interrupt we can draw from without angst.

So What Do We Do First?

There’s a bunch of stuff we need to do to build this commercialization decision.  That stuff becomes stories on our product backlog.  Our team is doing backlog refinement weekly, so our PO needs to write those stories, get them sized and prioritized, recognizing that he has only 10 points of interrupt for this sprint where he can jam in unplanned work.

Notes on sprint length (are you bored with sprint length yet?). This once again argues for one week sprints over two weeks.   Realizing that it will take at least a couple of days to create new PO stories, we could easily put off starting on them until next week in a one week sprint system.  In a two-week sprint system we’re forced to use interrupt buffer to accommodate the urgency of these PO stories.

 

 

 

 

 

About JR
Software guy, startup guy, non-fiction glutton, south shore inhabitant

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: