Don’t build shiny objects
Shiny objects are the features you release that arn’t supported by evidence the customer needs them.
Airwallex’s Richard Jeremiah gives his perspective on how Product Teams should triage the firehose of ideas, feedback and opinions that all compete for precious sprint resources.
In this short video, Contextu.al’s David Jones asks Airwallex’s Richard Jeremiah how they reduce down all features into the things that get built.
He cautions that all product teams have a tendency to “Veer off the path” :
- moving away from (measurable customer) “outcomes” to “output”.
- Teams often shy away from uncertainty to just making and releasing the new shiny objects.
Outcomes vs Output
For Airwallex and “Outcome” is focussed on customer value — this generally relates to an Objective or a Key Result in an OKR.
In contrast, an “Output” is just the result of keeping busy. This is often features that are built in isolation from customer needs. In other words, output is that new shiny objects are something the team saw in a designer’s blog post or a competitive product.
The challenge, Richard says is that “Outcome” is always way less certain than “Output” — an output is a known quantity, its just a matter of applying the resources and getting it released.
An Outcome requires much more validation and rigour to verify:
- Are we building the right things?
- Are shipping valuable things for customers
“Solving core customer problems is one of the great challenges of Product Development.” and “Get inside the head of the customer.”
Triaging competing requests
At the top of the product teams work funnel is a massive amount of options:
- Bugs to be fixed
- Technical debt to be re-factored. Scale and stability issues.
- Customer feedback captured in Zendesk etc
- Sales people claiming its imperative to implement ABC feature for XYZ prospect
- Team opinions
- New shiny objects and technologies
- validated feedback from customers
- results of experiments, hacks
- biased opinions from the product manager.
- and that old favourite….the fly-by CEO visit about something that’s been bugging them.
There is a lot to be triaged and having something like RICE is fine, but it’s rudderless.
Similar to what Zip‘s Patrick Collins advised the sprint needs to be filled with jobs that match to the customer and company imperatives.
Specifically, Richard says: Strategy →OKRs →Measures that reflect toward an Objective or Key Result/Outcome.
This top-down approach leads to using tools like Teresa Torres’ “opportunity solution trees” to ideate a range of possible technical and non-technical solutions.
From there a weighting or “sizing” (Richard’s term) for each initiative is used as another filter for what makes the sprint.
Summary
The summary is that new shiny objects will always be tabled as solutions to product problems or opportunities.
Its correct — the shiny objects may be a terrific solution! But you MUST run them:
a) through the lens of the customer’s needs
b) the organisational priorities and OKRs.
Originally published at https://contextu.al/blog/ on October 2
