Once we know the right thing to build, how can we help our teams build it right?
Product Lunch Club 16th April 2020
At this current time of lockdown, we’ve taken Product Lunch Club online in a new virtual format as we Stay Home and Save Lives.
This session’s topic was building the right thing in the right way — or in other words, once we know the right thing to build, how can we help our teams build it right?
Essentially this is a story of two parts — effective discovery and efficient delivery.
When we discover effectively we are more likely to delivery efficiently.
And it’s a subject close to my heart — so many teams waste time, money and resources building the wrong thing and only find out when it’s too late (usually post-delivery). This is not something agile can help us with — but it’s where we, as product people need to step up, reduce the feedback loops and increase confidence in the solution we are delivering.
It starts with ideas…
All pieces of work for a team start somewhere — often as defects to fix, or a problem to solve, but many start as ideas. These ideas come from research, competitors, or — as it seems — stakeholders, or otherwise highly paid opinionated people (the HiPPOs)
Therefore we discussed how to cut through the cruft and find the ideas worth pursuing — and how to do that when not all ideas appear to be created equal.
- Handle all ideas in the same way. Put all common ideas, opportunities, problems and defects into a common prioritisation space and treat them the same regardless of where they originated — be that research, discovery, HiPPOs or whatever. You may find that some — such as critical bugs or defects come straight out again, or you already know how important they are (i.e. critical impact) but the key is consistency.
I’ve sought to use 3 ‘backlogs’ in the past — a ‘back’ backlog for ideas, opportunities and the like; a ‘front’ backlog for items we are taking forward as product backlog items; and a ‘bin’ (accessed via the delete function) for those which don’t make the cut, or aren’t worth doing now.
- Move from ‘waiter’ to ‘doctor’ stance. This consistency is crucial if we are move away from simply building whatever is asked of us, to partnering with our stakeholders in a constructive and collaborative manner — which may involve pushing back where appropriate! In fact, saying ‘no’ becomes easier the less we say an unmitigated ‘yes’.
- Ask ‘what does success look like’? This is a good way to start a consistent approach to evaluating the value of each idea. For many ideas there may be no idea of what success looks like — far less any understanding of how it could be measured. It’s helpful at this point to set early expectations that we don’t want to be pursuing such shaky objectives! And as product people responsible for efficient use of (what could easily be) the organisation’s most valuable resources this is a right and proper response.
Itamar Gilad introduced his GIST framework at MTP Engage MCR this year. In a world of MANY ideas from many people there are many ideas which are not worth doing. At Bing and Google only 10–20% of experiments actually yielded positive results. At Microsoft only a third were worth doing — the rest neutral or negative. Itamar notes that around 30% is actually high — most of the time we’d do well with a 10% success rate…
Therefore challenge is finding and testing these 10% quickly and effectively!
Of course there will be times when we just need to JFDI — often at the behest of someone with much influence — where possibly our job and reputation will depend on how we comply. In these cases we are usually well within our remit to explore the implications and impact of such a request. In many cases success may be staying afloat, responding to market conditions or simply adhering to regulations. It should be remembered that many HiPPOs may actually have a well-informed ‘gut instinct’ fashioned over many years. In these cases let us follow their leadership but respectfully seek to measure the impact so we can learn together — and tune our collective ‘gut’ in the process!
It involves the team…
On the back of this we discussed the danger of becoming the bottleneck, or the only arbiter of truth. Instead we have a splendid opportunity to involve the team, and draw them into the process.
Not only is this a great way to prevent us from becoming the bottleneck, it means the team are also learning, and bringing their wisdom to the table. It can bring the team closer to experts in the business or amongst customers so they can experience problems first hand — or at least closer to first hand.
It is also a valuable opportunity to move away from requirement documents disguised as user stories — and move back towards ‘telling a story’ through conversation.
When to involve the team
They say the best time to plan an oak tree is twenty years ago but the second-best time is NOW. The best time to involve the team is at the beginning, but if that is not possible, then do it NOW.
We discussed how many product people already rightly practise high levels of transparency with their teams — sharing the vision, mission, roadmap and associated collateral with them at very opportunity. This means there are no surprises and the product benefits from the team’s collective wisdom.
We noted this doesn’t always need the entire team’s attention at once. Various methods can be employed to share information asynchronously and involve the team members to varying degrees. Some shared their experience with using a ‘three amigos’ style group to review and discuss high-level epic / initiatives, before doing more research, answering questions and further prioritisation before reviewing with the wider team if the initiative is deemed worth taking forward. This is a useful way to garner high-level technical feedback or estimates required for prioritisation or to assess return on investment (ROI).
As well as GIST, other ideas such as Dual Track or Ryan Singer’s (Basecamp / 37 Signals) Shape Up philosophy involve techniques we can try (John Cutler has written a helpful summary) but at the end of the day — it is culture and mindset which truly matter, not processes we use. More on that shortly!
How to ensure their involvement is worthwhile
In our role as stewards of the resources committed to us — as we try to avoid developing worthless solutions — it is also incumbent on us to ensure any team activity is worthwhile, and well planned.
We appreciate that how this happens can vary greatly depending on how well the organisation appreciates the importance of product discovery vs churning out features. However in all cases to prevent burnout, and provide designers and developers with enough time to focus and reach ‘peak flow’, we need to plan carefully how we involve them in discovery.
However we choose (be that dual-track agile or something else) we acknowledged that transparency and effectively demonstrating clear benefit and value for the development of the product are of utmost importance:
- Doing that pre-work to ensure the meeting is productive (see John Cutler writing more about this)
- Being clear on any meeting / workshop agendas and outcomes
- Rotating team members where possible to spread the experience around
- Accounting for time to be spent at sprint planning to prevent friction or over-realised delivery expectations
- Wherever possible taking opportunities to bring experts (or actual users if appropriate) into the refinement sessions to add colour and depth to the discussions
Over time, we anticipate team members will see the benefits and advantage to being involved, and appreciate the value of that time which helps prevent them coding or designing the wrong things — even if there is initial (or even continued) push back on this, where developers claiming they are ‘paid to code’, not do research or write backlog items, and teams using ‘spikes’ as a delay or defence mechanism.
So that together we win
As rightly pointed out — this is a cultural issue. In a ‘feature factory’, delivery team, or agency environment where cost and resource are tightly controlled the focus will be on simply getting features out. However in a mature and healthy empowered product development environment the team will have a greater appreciation of why they exist — that is to think, not just code. As noted at a recent Product in the (A)ether session:
“Your JOB may be coding, but it’s customer value that PAYS your salary”
On that basis all developers and designers probably should be IMMENSELY interested in whether they are working on the right things! (And to be fair many are — I’ve personally worked with some very astute developers who don’t want to waste a single byte.)
We also briefly raised the concept of ‘bets’ (ala Spotify DIBB framework), which can be immensely helpful here as a way to change the way team members and other stakeholders throughout the business approach product investment. On this basis Jeff Patton asks, how much we are willing to bet on the fact we’re building the right thing — the price of our lunch, or our holiday, or car / house / pension fund? As a general rule the bigger the bet the more confidence we require. Yet how often have we seen product development teams at a burn-rate of some many £k per sprint hammering away at something which eventually fails once delivered? Anyone spent the value of their house (a few £100K) on the wrong thing?
This makes the concept of measuring success at all stages all the more important. How do we know if we are winning or losing, succeeding or failing?
It continues after delivery…
If understanding success is important before we invest, measuring it as we invest is crucial. This means metrics are vitally important here. Not only do such metrics give us the information we need to assess and evaluate success, but they also give us concrete facts with which we can communicate with our teams, our users, and crucially for many — stakeholders and the wider business.
We noted this is especially important for work of a more ‘technical’ nature — be that a re-platforming project or efforts to tackle technical debt — where immediate value may not be clear. If we have meaningful metrics we can use to transparently highlight savings or tie up to important business outcomes we stand a better chance of being able to repeat such work and establish its value.
We concluded measurement — at least done well — is also a cultural issue. Regardless of what we say, the processes we may implement or even the steps we may take — mindset is crucial. As product people we are well placed to change our cultures by modelling and encouraging behaviours, explaining our choices and showing as we tell!
And it starts at the beginning — when we discover effectively we will increase our ability to delivery efficiently.
Here at Product Lunch Club 🥪 we’re a group of product people who meet regularly over lunch to help, encourage and support each other in our roles. Come and join us! 🍻
