From Progress to Product – a presentation by David Hussman

This is a summary of the presentation “From Progress to Product” that David Hussman gave at the ACE Conference in Krakow april 2016.

“Just because it’s done, doesn’t mean it’s right.”

Product Discovery session at DevJam, together with their customers they ask the following questions:
WHY:
– Frame – why are you doing this, what does success look like 3-6 months from now
WHO:
– Simple personas – to talk about who the product is for
WHAT:
– Trying to make interesting product guesses – this could be putting things in a backlog, but putting things in a backlog does not need to mean you are making interesting choices
– Stories, arranged from left to right in a design interaction way, and top to bottom in some kind of decomposition (story mapping)

Development:
– A product developer at DevJam first and foremost care about the product, second they care about maybe their skill. It’s like a guitarist in a band, unless you are a solo player you are part of something bigger than yourself and people come to see the band and not the guitarist.
– We are measuring the impact we are having, and not the progress we are making. Without progress you will have no impact, but if you think progress equals impact you are fooling yourself.

Sketching is a great way to break the chasm between development and discovery.

See also David Hussmans upcoming book “Products over process”.

1900 – Projects – Certainty – We just have to get it done, and then we will be successfull. Parameters: Time, Scope and Budget, and that’s what projects and project managers we’re revarded on (even if what was delivered was a piece of junk)
2000 – Process – Less certain
2010 – Product – Uncertain. Parameters THING, TEAM and TECH.

Context and continuum: (Where does your product sit?)
Two sides: (Not Should we use Scrum or Kanban)
* Uncertainty, things are unknown, dynamic, learn and experiment
* Certainty, things are known, static, construct and build

Product and team models:
– One product, one team
– One product, many teams
– Many products, many teams

Riffed of the Agile manifesto
– Measuring impact over Counting Story Points (Context and impact, who are we doing what for)
– Validated Learning over Getting Things Done (On the kanban board the column to the right is not “done” but “validated”.)
– Learning over Commitments
– “Too Big” over “How Big?”

One product, many teams
Scaling product development:
– more product learning, not more process
– don’t conflate scaling and spreading and don’t accidently increase process
One product, many team mappings
– Two axes: 1) Product, Market, Uncertainty 2) Structure (process, architecture…)

More riffs from the Agile manifesto
– Product Developers over Software Engineers
– Story maps over Epic Stories
– User Experiences over Single stories
– Customer journeys over Iteration Buckets
– Product Learning over Technical Constraints (you intentionally take on technical debt, not accidently. You can’t strive for zero technical debt)
– Learning faster over Getting More Done
– Discovery (KPIs) over Delivery (Pts)

Focusing on delivering stories instead of a user journey is like getting a list of groceries at the end of a sprint instead of a small meal.

How do we blend discovery and delivery? What can we learn outside of production?

Most of the time when we are talking about agile stuff we are talking about a delivery cycle. A better name for grooming is discovery. We as a team can choose before we start a sprint if we should focus more on delivery (getting more things built) or on discovery, trying to figure out what to build. As a developer, how well can you absorb customer empathy? How well can you tell stories? How brave are you to talk about things that aren’t programming?

Cross team validation tools, what can we learn outside the code?
Mixpanel is a web based tool that helps measure how users use your product
What do they need to learn in production? How wrong were they (product arrogance).

See also the story map tool CardBoardIt developed by DevJam