In the agile world its widely accepted that feature teams owning a complete product (aka Product Teams) are a good thing. The ability to ultimately own the entire product life cycle, and make tough decisions without unnecessary hand offs and approvals increases their effectiveness as a team.
A Product team will also usually own all the support activities of their product meaning they take a holistic view of their product. However, I still find that managing the conflicting needs of product development work compared to support activities is a huge challenge in many teams.
For me, addressing this really relates to creating the right mindset focused on finding the right balance between building new products and supporting them.
Why is balance important?
Product Teams ultimately have limited capacity. Although they can work on anything, they can’t work on everything.
This means teams need to prioritise future needs of their product with immediate needs of their product.
Once teams start to think about all the work as contributing to their change backlog they can start to focus on making sure they do the right work.
The goal for any product team should be to always do the “right” work irrespective of what they may have “allocated” for support activities.
Doing anything else, means the effort of the team will always be sub-optimal except in the rare situation that the value of “planned” support activities and the value of “planned” product development perfectly meets what was planned.
Instead, the ratio of actual effort spent on doing what is “right” can be used as an indicator influencing future decisions about where to spend their time.
The effort spent in each domain are really indicators about the quality of the product and can help you make better future decisions. A balance of 30/70 shouldn’t be taken as a bad thing but information to learn from.
On the other hand, although a balance of 70/30 may seem better, depending on what you team does it may be too aggressive or not aggressive enough.
What are Future needs
Future needs generally relate to strategic or proactive activities a team might do. They are based on the things they believe the product needs and are ultimately hypotheses about what problems our customers need solved and will be willing to pay for.
These needs can be created from your future roadmap, different security standards, monitoring & support agreements or a raft of other factors. Irrespective of where they come from, it’s easy to build the wrong thing because of the difficulty in predicting customer behaviour.
When trying to solve future needs, because of the difficulty in understanding what is required, teams should focus on validating their hypotheses in the quickest way possible with the least amount of work.
This is where build, measure, learn comes in.
In most of these situations teams should be looking to implement broad general solutions that provide the most amount of learning, steering you towards what you really need to build.
Figuring out what a customer really wants converts a future need into a today’s need.
What are Today’s needs
Today’s needs are generally tactical and reactive activities based on clear indicators about a customer need. These are based off actual usage data and reflect things that will add immediate value if solved. These come in the form of things like support requests, production incidents, security attacks, performance data, and a raft of other indicators you may be monitoring. The trap with the needs of today is that it can feel so good solving immediate problems that you can get stuck spinning your wheels.
The real challenge here is that in the long term you can’t solve reactive work by doing more reactive work.
An example of this would be a team receiving repeat requests or incidents of the same type should shift their focus to automating the requests to be self service or improving the quality of their product in a permanent way.
What does this look like in real life?
Every year in Australia we suffer a lot of bush fires. Our amazing firefighters work hard all year round protecting us and making sure the risks of bush fires are contained.
Not only do they react to fires that come up unexpectedly but they also proactively combat them. They are never able to prevent fires from starting though because it’s not possible to predict where a fire will start.
Every day fires are generally controllable but every now and then a bush fire that is uncontrollable starts. The firefighters know that for bush fires, purely reacting just won’t work.
Sure, the first thing they do is to try to immediately extinguish the fire, but once they realise the bush fire is out of control they quickly move to redirecting effort towards more proactive strategies like clearing combustible material far away from the main fire.
The fire fighters use the information about the immediate needs of Today’s to inform what the right work to do next is.
The secret is balance…
The art of balance
Like our firefighters the most important thing a Product team can do is to understand where they are spending their time.
There is no such thing as a “perfect balance” so team should never attempt to work towards a perfect targeted. Doing so guarantees sub-optimisation.
A product team needs to understand the real goal is to find the right balance.
Building for the future helps you make sure your product is relevant for the future, but supporting today’s needs helps you capitalise on the opportunities of today.
The amount of effort a product team spends on either side of the equation (Future needs vs Today’s needs) is a valuable information source. When the volume of work for today’s needs is too high, instead of investing more resources and time on solving more of today’s needs you should consider restricting the amount of effort they are spending on today’s needs and solving these problems in a more sustainable way. This may mean improving the quality of the product or streamlining the support functionality the product currently has.
Although I’ve used this concept to describe a product team’s responsibilities this concept is transferrable to any team that balances proactive work with reactive work.
