A month after launch

A much-awaited upgrade to your application went live 4 weeks ago. It was probably the most organized launch that your company has done so far. It hit production well on time for a start! Customers logged in on Monday morning to an in-app announcement about the new functionality. The team felt great for making it over the line. The marketing collateral followed on the brochure site and your social channels at 2PM UK time to ensure that American customers saw it first thing in the morning. Usage tracking was carefully thought out to follow the user journeys. KPI dashboards were defined well in advance. For once, the engineers and product manager felt like they shipped something calmly and confidently.

But, here you are, 4 weeks later. Frustration. Extremely poor uptake from users. Did people even notice that it was there? How could they not? You told them via email, in-app message, Twitter, Facebook, LinkedIn; you name it. No conversions to the premium package at all. What on earth happened?

The engineers are feeling deflated after such a disappointing launch. Product are getting their fair share of blame for the lack of usage, especially taking into account how long it took to build, and the features that the team couldn’t build while it was underway. The situation comes to a head in the team’s weekly meeting whilst analysing the usage data. A snide remark from one of your engineers starts it off.

“Well, the usage would probably be better if the feature was more interesting, right?”

Your product owner, rightly, goes on the defensive, but withholds her anger.

“We were all behind this being a success a few weeks ago. What makes you say it wasn’t interesting?”

“It’s just not a particularly smart feature. We could have done so much more with the algorithms that recommend content. It’s pretty simple to do as well.”

“Right. So why didn’t you suggest any of that when we were designing it?”

“That’s not really my remit; I don’t really know what the customer wants,” exclaims the engineer.

“But you just said it could have been much better! You knew how, too!”

“But that’s not my call, is it? You’re the ideas person, right?”

Working with product owners

The fictitious situation above is a riff on a real situation that I have experienced countless times. As soon as the relationship between Engineering and Product becomes anything other than symbiotic, you’re asking for trouble. In an ideal world, a strong engineering lead (or team) combine with a strong product owner and, like Voltron, become a force to be reckoned with. The engineering team bring innovative technological ideas and a knowledge of what is and isn’t possible, and the product owner brings clarity on customer needs, the job to be done, and the predominant feature ideas that can satisfy these needs.

You’ll repeatedly read that a “healthy tension” should exist between Engineering and Product. This is true. However, this can also be interpreted wrongly. It doesn’t mean that there should be purposeful conflict and loyalty to sides; instead the tension should exist between innovative ideas and their possibility within real-world technical constraints. Additionally there is an ongoing tension as to when to pay down technical debt rather than consistently rolling out new functionality.

But I mentioned the term symbiotic for a reason: a feature team without a good product owner is stunted in their ability to do their most impactful work for users, and a product owner without a good engineering team is unable to deliver their vision.

What happens when the relationship isn’t symbiotic?

Silos: Where both Product and Engineering metaphorically exist on two sides of a wall. Product throw ideas over the fence at Engineering, who blindly implement those ideas as best as they can. Engineering don’t “do” ideas: If your engineering team refuse to take ownership over what they are building as well as how, then you can find yourself with a blame game when things go wrong. Also, a wealth of interesting ideas from Engineering go unsurfaced. Product don’t “do” implementation: When Product don’t take an interest in how things are built, with a longer term view to understand better how engineering constraints work, then a product owner can miss the trick of learning how to better engage with engineering teams, and also question and critique their approaches.

Let’s dig into all of these in more detail.

Silos

To begin with let’s talk about collaboration. Even though in theory you have your product owner owning the strategy, ideas and ultimately the backlog for the team, and likewise, you have Engineering owning the implementation, if both parties are not collaborating deeply then the software will be much worse off.

Let’s consider a hypothetical situation where a product owner doesn’t talk to the engineering team at all. Instead, she just makes sure that their backlog is well-defined and always up to date. Now, assuming you have a perfect product owner and a perfect engineering team, then this isn’t necessarily a catastrophic problem for the business: new stuff will still get shipped. However, the sad part of this situation is that it could be so much better.

In reality, no engineering team is perfect and no product owner is perfect. There will always be frustrations; things may take much longer to build than originally thought (or may be impossible), and some product requirements may come through half-baked. It happens. Both parties collaborating and having opportunity to discuss ideas and technical approaches, purely from a critical thinking perspective, can only make the whole project better.

Not operating in silos also contributes to everyone feeling enfranchised. If the engineers feel that they have no input in the product direction, then not only is it harder to get inspired about building new functionality, but if stories are poorly defined, or technically impossible, or if the functionality lands badly with customers, then the fingers will point and blame will be thrown.

It should be a two-way street. If we instead consider Product’s ownership of ideas and Engineering’s ownership of implementation and rephrase this as accountability instead, then we can imagine ways that both parties can jointly have more input in each other’s worlds.

Engineering don’t “do” ideas

This one can really bugs me.

There are two facets to this argument that I disagree with. The first is covered above on the effects of siloing Product and Engineering. If the engineers are not willing to engage with their product owner when they are coming up with ideas, then they’re missing out on improving them by offering their own thought and critique to the process. Product can have the accountability for those ideas, but input from smart people in any role can only improve them.

Engineering should do ideas. Here are some of the ways that your engineers can improve a product roadmap:

Identify useful functionality with little engineering effort . It may be the case that spending a short time upgrading to the latest version of a relational database or search index could bring a whole host of cool features for free, i.e. new ways to aggregate data, the ability to do free-text search, or the ability to perform joins that were not possible previously. It may be the case that newly built functionality (e.g. a new type of visualization) can now be extended quickly and easily to roll out variations of this feature in a comparatively short space of time. Stand on the shoulders of giants.

. It may be the case that spending a short time upgrading to the latest version of a relational database or search index could bring a whole host of cool features for free, i.e. new ways to aggregate data, the ability to do free-text search, or the ability to perform joins that were not possible previously. It may be the case that newly built functionality (e.g. a new type of visualization) can now be extended quickly and easily to roll out variations of this feature in a comparatively short space of time. Stand on the shoulders of giants. Suggest new technology that could improve a product. Following the open source community can highlight when an interesting new piece of technology is available to use. The engineers can suggest that bringing that piece of technology into the stack can unlock all sorts of new features that may have previously not been thought possible, or even considered at all.

Following the open source community can highlight when an interesting new piece of technology is available to use. The engineers can suggest that bringing that piece of technology into the stack can unlock all sorts of new features that may have previously not been thought possible, or even considered at all. Come up with entirely new ideas! Technology aside, engineers are smart folk who use software extensively as well as building it. What have they seen in other applications that could be an avenue worth exploring in their own?

So, in short, yes: Engineering should do ideas, and collaborate with Product to work them into the roadmap. Your engineers will learn about Product’s role in making priority trade-offs which is a key entrepreneurial skill that is a benefit to anyone if learned.

Product doesn’t “do” implementation

Well, it’s true that your product owner won’t be committing code, but it shouldn’t prevent a healthy curiosity about the development process. Great product owners have a natural feeling for how complex a given feature is to build and are able to work with an engineering team to balance quick wins and long-term plays to ensure that software is shipped with a predictable cadence.

Here are some of the ways that product owners can contribute to implementation:

Push for small increments to demo: This may be the most obvious point, since it’s a repeating topic in agile literature. However, engineers may not naturally think about how demonstrable their work is (i.e. deploying feature branches, knocking together a quick UI, preparing a data dump for display), so a product owner can act as a lever for the understandability of what his been achieved by the team. This helps the whole team communicate better to the business. How can we show that this piece of work has been successful? How can we track the usage of that change? How can you show me that the storage upgrade has been successful and worth our time?

This may be the most obvious point, since it’s a repeating topic in agile literature. However, engineers may not naturally think about how demonstrable their work is (i.e. deploying feature branches, knocking together a quick UI, preparing a data dump for display), so a product owner can act as a lever for the understandability of what his been achieved by the team. This helps the whole team communicate better to the business. How can we show that this piece of work has been successful? How can we track the usage of that change? How can you show me that the storage upgrade has been successful and worth our time? Offer critique in design sessions: Designing software is all about logic, and to an extent, it can usually always be abstractly represented by diagrams on whiteboards. Instead of backing away from these sessions, product owners can sit in and ask questions for the benefit of improving the group’s critical thinking. Why do we need to build that part? What sort of speed will that return at? Is this how we tackle the problem elsewhere in the system, or is this totally new functionality? Could this API be used elsewhere in our software by another team?

Designing software is all about logic, and to an extent, it can usually always be abstractly represented by diagrams on whiteboards. Instead of backing away from these sessions, product owners can sit in and ask questions for the benefit of improving the group’s critical thinking. Why do we need to build that part? What sort of speed will that return at? Is this how we tackle the problem elsewhere in the system, or is this totally new functionality? Could this API be used elsewhere in our software by another team? Expanding their knowledge of how things are built: By spending time discussing ideas with engineers and seeing abstractly how parts of the system are constructed, a product owner increases their feel for how challenging future work is. In addition to better understanding the complexity of their own roadmap, they can look at competitors and have an intuition of how they are solving particular problems (i.e. what data are they storing and how? How often does it refresh? Is it cached or computed on the fly?). This improves the working relationship with engineers. There is a common understanding about size and difficulty, and a deeper understanding of technical debt and implementation trade-offs.

In summary

Don’t work in silos. Collaborate. Engineers: you’ve probably got more product ideas to offer than you think. Product owners: you don’t need to be scared of implementation. Be curious, explore and offer critique.

Engineers shouldn’t feel that they exist to blindly serve product owners, and product owners shouldn’t feel that they can never get involved in the process of creating software. There are ample opportunities for both roles to understand each other much more deeply and improve their own skills. After all, both roles exist in order to deliver value for a business, and that’s the North Star that they all should be pointing towards.