A friend of mine recently came back from a visit to a pretty successful software company, and one of the things that impressed him most was how well their engineering and product people know about each other’s domain. Engineers know about the why of the product, the rationale behind certain feature decisions, and the plans for the future. Likewise, product people know, at least in rough terms, how the software works, how it is structured, and what design decisions and tradeoffs are in place.

This is not a matter of course. There are developers who just want to code, and who do not want to bother with product strategy or feature design. And there are product owners who are rather un-technical, and who are not that interested in the differences between Indexed DB and Web Storage, and which one is preferable to the other. However, this can be harmful to the overall product, because a lot of potential might remain unused, and alignment is not as easy as it could be.

Small decisions with a large effect

Potential can remain unused in several ways. Firstly, if developers do not know the context in which their product is used - the why, not just the what -, they are less likely to deliver the product the user needs. Consider a map application, and the following initial requirements:

• As a user, I want to be able to click on a location on the map in order to create a marker at that location. A tooltip should show up that allows me to label the location.
• By clicking on an existing tooltip, I want to be able to edit an existing label.

These are fairly concise requirements. However, the context is entirely missing. Most notably: What kind of locations do the users mark? Are they locations that are dangerous for pedestrians? Are they meeting points? Are they sights and attractions? Are they donut shops?

Not knowing the nature of the marked spots, a developer might decide on a storage schema optimized for retrieval of markers by geospatial location, because that is the thing you would probably expect from a map application. However, what if the purpose of the application is for users to mark their home towns, and the customer - the “owner” of the application - wants to observe how his application spreads over time throughout various nationalities by following the home towns of its users. Suddenly, marker retrieval has to happen ordered by marker creation time instead of geo coordinates, and the initial storage schema is wrong.

Moreover, what about the labels? Suppose we do not know the thing about the home towns, we will be wondering what kind of text will the user put in there. Just one to three words? A whole paragraph? Their year of birth? What about the device context? Is the user likely to be using a smartphone, or will she rather be on a powerful desktop PC with a low-latency connection?

Depending on the answers to questions like these, a developer or designer might make very different decisions when it comes to things like input processing, feature variations, click and touch handling, storage layout, and other aspects of the application. Features usually can and should not be specified down to implementation details, so it is the engineer’s job to make certain tradeoffs and decisions. These decisions are not business decisions, but they can still affect the usability, performance, or maintainability for the better or for the worse. The more context an engineer has, the better these decisions will be for the users, and for the long-term health of the system.

You might say that it is the product owner’s responsibility to shield the developers from stakeholders and their requests, so that they can focus on their work. That the product owner acts as a filter of the outside world, which keeps away unnecessary details. However, if the PO filters out too much context, the developers will be blind to the big picture, with undesirable consequences like in the example above.

Mining for ideas

The second way in which potential is wasted is that you might miss out on valuable ideas if you do not involve developers - or designers, or QA engineers, for that matter - in product strategy. Different perspectives can help make a feature more complete, more usable, more innovative, better looking, and many other things.

If the map marker application mentioned above was about sightseeing, it might be beneficial to run a clustering algorithm on the marked locations, and use the clusters to find efficient tours that cover the selected attractions. If the application is about leaflet distribution to households during an election campaign, and the locations represent the homes of campaign helpers, a Voronoi diagram could be used to assign certain areas to each helper. These kinds of algorithms are typical things a trained computer scientist can contribute, but these suggestions will not come up if the context is unknown.

Sometimes, technological advancement makes new features possible. Developers are usually familiar with the technology at hand, and can point out possibilities that might still be unknown to others on the team. For example, service workers can open up a wide range of new features to many products, but if only the developers on the team know what they are, and if these developers are not asked for feature ideas, they might never see the light of day. This is unused potential.

Degrees of context

The map marker example above is quite extreme, in that virtually no context is given at all. However, the boundaries are fluent, and the greater the shared context, the greater the participation and involvement of everyone can become. Some various degrees of shared context are:

• Zero context given (see example above)
• Team members know the typical use cases
• Team members know the problem domain to some degree
• Team members know the strategy
• Team members know the reasoning behind the strategy, and what alternatives were considered

This is the direction “from customer and product owner to developers”, but it goes both ways. Developers should tell their product owner (and/or stakeholders, if they are sufficiently technical) about the important software design parameters, design decisions, and tradeoffs.

We could have used library X, but it was too large and would have increased our initial load time. Therefore, we used library Y, which is smaller than X and has the most important parts of its functionality, but that means we cannot do Z the way we planned. We need to rethink a bit.

Or:

We have to use some caching on the stock data for performance reasons. We found out that a time-to-live of 10 minutes gives us the most up-to-date result in 91% of the times. Reducing the TTL to 6 minutes gives us 96%, but it also means we have to get two more servers if we are to go to full traffic. What do you think?

Or:

The way we organize the data makes reading very fast, but updates suffer from low throughput, because several indices must be reorganized. Since we are faced with a read-mostly environment, and expect high traffic, this is the compromise we chose.

If POs know, at least on a high level, about these kinds of technical design decisions, they will have an easier time explaining to the customer why certain things are not possible, and what their options are instead. Moreover, they will be able to discuss the tradeoffs with the developers, and name their preferences in system design discussions.

It’s everyone’s business

In his great book, The Five Dysfunctions of a Team, Patrick Lencioni describes a group of executives who do not work very well together. A new CEO named Kathryn is brought on board and shows them new ways of developing trust and collaboration between each other, so that open discussions and candid feedback are possible within the top management team. It’s a great read, I can definitely recommend it.

Anyway, Kathryn, the CEO, at one point asks the Head of Sales what the Marketing figures of the last quarter were. He does not know. She goes on to ask the VP of Engineering about the Marketing figures. He does not know, either, and sarcastically remarks that the Head of Marketing might be a good candidate to answer this question. However, Kathryn insists that marketing is everyone’s business. Just like sales is everyone’s business, and, yes, engineering is everyone’s business. If you want to collaborate effectively, if you want to identify synergies, if you want to discover opportunities and drive innovation, then you have to know at least a tiny bit about each other’s goals, challenges, and plans.

The same can be said of a mixed-function product development team. Product strategy is everyone’s business, just like engineering, QA, user experience, and design. At least the leading people in each function must have a considerable information and knowledge overlap with other functions. If that is the case, their forces will multiply. If it is not the case, they are not a real team, but rather people who sit close to and work alongside each other.

Fostering collaboration

So how can you achieve such collaboration? I think the good thing is that it does not take much. You can start very small, but also go up to rather big events. These are some ideas:

• When planning for a quarter, get the other functions involved. Don’t just send them the result of the planning process “FYI”.
• Show interest in each other’s work. Make the first step. Few people will angrily drive you away when you ask them to explain how they have solved or are approaching a certain problem.
• Review each other’s work and results. Developers should be somewhat familiar with the relevant business KPIs. Likewise, product owners should have access to code metrics overviews, and have a feeling for what is good and what is bad.
• Department-wide presentations on certain topics. If you are planning a large-scale refactoring, explain to everybody why it is necessary, and what the risk is. Similar presentations can be given for product strategy.
• Have interdisciplinary Open Space events where people can share knowledge and come up with new ideas in a relaxed atmosphere.

I cannot give first-hand reports on the success of all of the above methods (my company is experimenting with Open Space events, though), but I think it all starts with a certain interest in and respect for other people’s work. If you can muster that, you will find a way of acting on it.

Conclusion

The message that I want to bring across is that whenever people of different functions work together - which is all the time, for most people I know - they should take the time and effort to learn about each other’s work. I feel close to singing “Kumbaya My Lord” when I say it, but we work better together than in “finish your step and throw it over the fence” mode. Product and engineering work better together. Design and UI development work better together. Engineering and QA work better together.

Of course we have specialists with unique talents. However, if team members understand each other’s goals and challenges, as well as the big-picture context of the product, this team will achieve tremendously better results than a team that is actually just a group of people sitting close to each other.