The feature domino effect

Editor’s note: This is a blog post by Sherif Mansour, a Confluence legend, and one of our talented Principal Product Managers. He is pretty awesome at building product, lego, and is also a wannabe designer.

When my son was younger I often spent time with him lining up dominos on our long coffee table. After a good five minutes of placing dozens of dominos perfectly in a line, he would jump back to the start of the table and yell “daddy, daddy… go!!!” waiting in anticipation for me to push the first one over. I’d give it a little prod and the domino effect would go for a total of… two seconds (at most), making you feel like you just wasted the last few minutes of your life.

I wondered what he found that was so intriguing. Was it seeing the effect of one domino push another one over? Was it the sound they made? Or was it simply the anticipation of seeing the dominos collapsing? After doing it a few times, I felt like it was mostly about watching a cascading side effect take place. As we’re lining up the dominos I don’t really think he’s thinking about what it will look like once they’re all lined up. And, once they are ready, you push one over and watch the effect happen to each domino down the line.

Seems like a pretty simple concept… a domino effect. We see them in the physical world but I don’t think we think about them enough when we’re building product.

Solving a problem will often push you down the path to solve other problems you may not want to solve.

How many times have you been caught in a situation where you’re presented with a “quick win” or small improvement you could place on the roadmap. This appears quite harmless and why would you say no to something that adds some value to your customers with little effort? “Sure, let’s put it in” you hear yourself say.

You ship it. Shortly after you find out that you’re getting feedback about another problem. You may or may not have already known about it, but either way, you weren’t hoping to tackle that problem anytime soon. Turns out that this problem always existed, but it has become much more apparent to your customers with that little “quick win” you introduced.

Beware of the domino effect

The feature domino effect — did you see it coming? Often we don’t. This is largely due to the inherent nature of how these things appear on our roadmaps. They typically come through someone’s side project or a person noticing we could improve something while we’re working in a particular area of the product.

Let me be very clear: I’m not saying these are bad problems to solve. They can often be a great source of innovation and usually come with a good cost/effect trade-off. What I’m getting at is that we don’t think thoroughly enough about the consequences of slotting one of these into our roadmaps before we make a decision.

Every product decision is a tradeoff and we must think about our product roadmaps as a set of decisions.

Here’s a simple, but hopefully symbolic, example. One of the products I work on at Atlassian is Confluence. Confluence is a content collaboration tool for teams to help them create, organise, and discuss work. Content is grouped into workspaces (we call them “spaces”). In one release, we made a visual change to the product. We modified the main header navigation to go from only showing the page location…

to showing the global objects in the product.

It wasn’t a big change in terms of engineering effort. In fact, it was one of the engineers working in this area who had the idea of putting the space navigation up the top — enabling our customers to navigate between their various workspaces. So I did what every good product manager would do and asked “Is it a quick win? (Come on, you can’t tell me you’ve never done that before!) Turns out it was a pretty quick change. So we modified the header to incorporate navigation to our space directory.

We didn’t think about the domino effect. Shortly after, we received a boatload of feedback that our space directory (what you were redirected to when you clicked “Spaces”) was quite tedious to work with. We didn’t have in our immediate roadmap plans to improve the directory. Don’t get me wrong: the directory needed improvement. It was slow, difficult to navigate, and prior to surfacing this customers, they had found other ways to navigate around the product. But once we put the link to the directory there, usage went through the roof. Was improving the space directory valuable? Yes it was. Was it the most important thing we had to work on at the time? No, it wasn’t. Did we see this coming? Nope, we didn’t. I could probably find dozens of more pressing issues we had to work on, including the need for us to focus on our current in-flight projects. I failed to see the cascading impact of the feature domino effect.

Seeing the domino effect before it comes

There are a few techniques we’ve been using to understand the implications of these product decisions. It’s important to note that you need to contextually apply these techniques to each of your product improvements. The nature of these domino effect problems comes when we’re thinking something is small enough to not warrant a little bit more thought.

So how do you make sure a “quick win” doesn’t become a “quick win for which we’ve under-planned and is no longer a quick win”? How do you find the right balance with how much rigour you should apply to these, often small, improvements?

Agonise over the hard-to-reverse decisions and move fast with all the rest.

The best technique I’ve found is to ask yourself and the team if this is a hard-to-reverse decision. If it’s trivial to reverse, move forward, then go ahead and build, measure, learn. If it may take a significant effort to undo on your roadmap, spend some more time doing your homework — learn, measure, then build.

There are lots of other techniques to help you predict the domino effect. They all revolve around trying to “play the movie forward” and making assumptions as to what may happen as a result of change. Here are two of my favourites:

• Team brainstorming sessions: Inform your team about domino effects to help you scale this type of thinking across your product. Hold a simple brainstorm session where you ask “What new or existing problems might we surface after building this?”. During the exercise, ask each member of your team to wear a different hat to foster diversity of thought. Take the outcomes of the meeting and ask yourself — would we be prepared to solve those problems? Would their priority take precedence over other things?
• Journey mapping: During this exercise, draw, screen capture, sketch (or whatever) each step a user would take in a particular journey to use this feature. Start from logging in. Once you’ve done this you’ll be able to quickly visualize and answer what other things will be surfaced by implementing the particular improvement you’re looking at.

I mentioned earlier our product roadmap is effectively a set of decisions. The feature domino effect can be one of those decisions you don’t even think you’ve made. Our job as product managers is to ask the question — are these the most important problems to solve?

So beware of the lure of quick wins. These improvements may solve real problems, but might also distract you from your main mission.

Did you enjoy this post? Want more of the same? Consider following Designing Atlassian.