Facing your fears…technically

As a Product Managers we are all probably familiar with the Venn diagram showing the three main user groups that we need to consider when building new products and services: Business, Users and Tech. But what happens when you get the balance wrong? What happens if you start to lean in favour of your functional friends and focus on business stakeholders and your users and you forget about the non-functional aspects of the service?

As a Product Lead at Kainos, one of the key parts of my role is ensuring that the technical aspects of the services we are building are considered and prioritised in our roadmap. Here I am going to explore some of the problems it can cause when we don’t focus on the functional as well as some handy techniques I have picked up over the years that help me to focus on these when building digital services.

Feature Factory

Let’s start with the humble bike, imagine a children’s bike… we should all be able to picture one, it may your son or daughters or one you imagine having as a child.

You are probably thinking of something that is small with little wheels, some of you might be thinking of one with stabilisers or with colours of your favourite television character. So, if we find ourselves being stuck in the feature factory mindset we focus on solely on features and can easily fall into the trap of adding more and more features.

Just think of all the things you could add to your bike to make it even better. You could add a bell or a bag or even get some brightly coloured accessories. Before you know it you are going to find yourself with something that looks like this….

Here is a children’s bike that is packed with features, it has just about every feature you could think of, coloured streamers, a bag, pink tyres a bag and a bell.

The problem with continually adding features to the bike is that whilst it has loads of unique features - it is still just a bike. None of these features will address the non-functional aspects. They won't make it any less likely to break, it wont make it any less likely to steal, it can still only carry one person. If you start to think about some of these aspects you begin to think of the non-functional aspects.

Uncovering technical items 

So what can we do to ensure we focus on the non-functionals and uncover those technical items to add to our roadmaps?

I like to start by thinking of the negatives, thinking about some of the risks that I can spot when building a product. Take our bike, for instance. What good is it if you can't ride it as far as the park without the wheels falling off, or if the brakes are not powerful enough to stop it when going downhill.

Talk to your teams and your technical architects, find out what they are worried about. I don’t always know the technical details, but I have built strong relationships with those around me and get their help to uncover things. Don't be scared if you are unsure or don't understand, in my experience I have never been told to go-away if I wasn’t sure about something. More often than not, my technical colleagues are really happy I am taking an interest.

Another tip - think of how your product will perform in different scenarios and again think of the negatives.

“What if we are really really popular when we launch, how do we ensure we can handle the demand?"

"What if someone decided to target us, how do we ensure we have protection against cyber-attacks in place?"

"How do we ensure we can effectively support the service if there are any issues, do we have any monitoring or alerting in place?"

When building our roadmaps, we need to ensure that we are considering all the things that sit below the surface, feature development is literally just the tip of the iceberg when it comes to building successful products.

Make them visible 

So, what do you do when you have uncovered a list of technical items, how do you feed these into your roadmaps?

Visualise the items you have uncovered by giving them a name and describing them in simple terms and then including them in your backlog of items for consideration in your roadmap.

I like to use the following format:
Name - Refer to them in simple terms, describing the outcome they will bring,  e.g "Ability to receive alerts when there is an issue"

Description - Describe the problem of not addressing these and the risks e.g "Currently, we don't know if there is a problem with our service and sometimes are informed by our users there is a risk that there will be reputational damage because of this"

Outcomes - Describe the risks and how the outcomes mitigates these and outcomes that will be delivered e.g "Proactive alerting is put in place for all services, support team notified…"

Give them a score

After you have them documented, you need to socialise them; bring awareness to them with your stakeholders, don't hide them. They should form part of your prioritising and planning for your roadmap.

Prioritising technical items can be a challenge; it can be hard for stakeholders to prioritise a technical item against a feature that they know and love. There are some techniques I have used in the past to ensure that technical items get the focus they deserve.

One of the techniques I use is a value framework. This is a simple framework that can be used to score each item in your backlog. The idea is that you look at a particular item and  assess it against 4 key criteria (Reputation, Policy/Legal, User, Risk), impacting this against the impact if this were to happen (low, medium, high). When you have your scores you can then order your backlog in order of value. This then gives you a single view of all the items in your backlog and can help give the necessary priority to those non-functional items, raising them above the functional items. You can then apply other lenses to these items to narrow the funnel and identify the most important thing to do next. Some other lenses to think about are complexity, t-shirt size, readiness for a team to pick up etc.

Summary

By going through the above steps we as Product Managers can ensure that we are uncovering technical items by working with stakeholders, peers and our teams and ensuring that we deliver performant, secure and robust digital services. If we take time to:

• Make these items visual, describing them in an easy to understand way and drawing out the risks associated with not addressing them
• Describe the benefits and outcomes that will be delivered as part of the work
• Give them a value that everyone can see
• Prioritise and plan them into the next phase in your roadmap

You can face your technical fears and bring your roadmap back into balance and build successful products!

Credits

Children’s bike: Available from Amazon

Iceberg image: Nature Vectors by Vecteezy