Don’t just build the thing right – Build the right thing

Right now I’m a CTO but I’ve had many different roles in different companies and different countries. I’d like to take you through a portion of my career and what I’ve learned along the way.

The part of the story I’m going to share starts around 10 years ago. I was a developer and then a team lead. My goal was to ship code: quality code and to build a happy team. I wasn’t really involved in what we’d build; I’d get told what to ship and we’d ship it. Working in that way carries the danger of becoming a feature factory. You get something live then move onto the next world-changing idea. Then the next. And the next. Rinse and repeat.

My wife is a product manager in a digital business while I was an engineering manager and it sometimes felt like we were coming at the same problem from two different angles. But over the years I’ve learned from her and from others. Here’s a few of the things I’ve been exposed to.

Portfolio Boards

My first CTO role was in Kuala Lumpur – 6000km away and in a company without anyone running product across the group. Suddenly my job wasn’t just leading a team of developers and testers, now I was responsible for all of technlogy and my colleagues were looking to me for guidance on what to build. Being a group of four different sites, there were always many new ideas to tackle and conflicting demands on time. My first instinct was to fall into the trap of saying “yes” to everything.

The way I tried to get off that train was to start making it very clear to myself and to my stakeholders what the team were working on. The act of getting the information out of the tracking tool and onto cards on a wall can help. Many teams will be familiar with this approach at the team level – story cards moving across columns on a kanban board each sprint. The idea here is to do that at a project level where each card represents a project you’re working on.

This is an example of a very simple portfolio board from my current company which shows what projects we’re working on and what’s coming up. We can show this to the MD and he knows what we’re talking about. In fact, since the photo was taken, we have also started keeping a copy of this in Trello.

When information like this is hidden away in a spreadsheet or a detailed task tracking tool, you don’t get the same feeling for how big the work you’re taking on is.

You can expand on this and start putting work in progress limits in – this requires buy in and support as it means stopping work that is currently in progress. An interim step (which is where we are now) is to set some prospective limits and then just observe where you are in relation to those limits to get a better feel for whether you’re taking on too much.

Of course, even with a visualisation of what work you’re doing and a set of strategic themes, you’ll always be bombarded with new requests – especially from executives.

Impact Mapping

That’s exactly the problem I faced in my next role. Along with a commercial counterpart, I was in charge of a new two-sided platform at Australia Post. As with any platform, you need to onboard both consumers and producers; without the consumers, the producers won’t come onboard and without content from the producers, the consumers won’t stay around.

As a new product in market with a lot of corporate attention, we had been on the train of delivering feature after feature after feature and the list wasn’t getting any shorter. Then we were introduced to Impact Mapping – a strategic planning technique for goal-first development of a plan.

Here’s a fictional map for a marketplace business. You can see the goal we’re after is increasing live products on the site by 50%. There are a number of actors who can help or hinder us – retailers both current and prospective and people listing classified ads. We fan out by listing the impact that those actors can have – listing more products, linking ads to products or even a new retailer signing up to add their products.

We then take it to a deliverable which will help the actor achieve that impact – perhaps if we improved the listing flow or autosuggested products then retailers and private sellers would add more. And it’s important to note that the deliverables aren’t necessarily IT projects – sales, marketing and partnerships can all have impacts too.

This can be done at many different levels – from a high level business-wide KPI with major strategic projects as the leaf nodes down to a product-level goal with epics or user stories as the deliverables.

By building an impact map from a goal and fanning outwards, you can make sure that everything you’re doing comes back to affecting the goals of the business or product.

Of course, plans are one thing – you also need to know that you’re heading in the right direction

Metrics that Matter

At my next role, we were launching a number of entirely new products into market – some of them were addressing the market in quite a different way. We were given the space and permission to run the product as a lean startup – putting together a small cross-functional team to build and iterate on a product with customers. Once we got the product into the market at the start, we needed to know if what we were doing was on the right track.

One of the tools we used were the Pirate Metrics – as developed by Dave McClure. They are AARRR – Acquisition, Activation, Retention, Referral and Revenue. This is a funnel going from the people who visit your product – to them having their first delightful experience – then returning to visit again – telling others about their experience and finally to making money for you.

An example funnel might look like this:
100% acquired (hits to the product)
54.5% activated (engaged user actions)
20.5% returned (return visitors)
0% referred (shared content)
0% revenue (paid indirectly or directly)

From this we can see where we have to focus – on why people aren’t sharing and how to get revenue from users. We knew the current state, so the next step is to iterate from there to a target condition. At my next role (which is my current), we’ve taken to using a framework that allows us to do that.

Product Kata

Toyota Kata is a Continuous Improvement framework that creates the habit of improving by focusing on learning. It’s about creating small experiments to solve problems. Melissa Perri took the Toyota Kata and applied it to product development.

Her approach starts with a statemet of the direction – a product KPI we need to achieve (maybe one of the pirate metrics). It then studies the current condition – what are users doing, what is the product doing. It sets the next target condition – this is a small step we can take to get us moving in the right direction. This then leads us into an experiment loop – using a plan/do/check/act cycle.

The important part of this is making this a repeatable process that you do consistently for every small iteration. It’s a way to gain “muscle memory” on your continuous improvement activities.

Here’s our first attempt at tracking an improvement using our own interpretation of this method. We’ve defined the problem, the target condition, a definition of success and then 3 small actions we can take to get further towards the target condition. We can then review this with the team in regular increments. We’ve only just started using this but just spelling out what we’re trying to achieve and making it visible has already helped change the conversations we have.

Andy Kelk