The one thing all successful software companies have in common is their ability to build products that their customers will pay for.
However, there is a lot of work that goes into building a successful digital product. From understanding the user needs, brainstorming user flows, designing interfaces and architecture, to implementing, testing, and finally rolling out the features.
All of these steps require the participation of different teammates with diverse skillsets. And yet, even in agile environments where collaboration is encouraged, a common issue I see is that product owners bear the sole responsibility of the product vision and often fail to include input from other team members.
Alone, they come up with ideas about how a feature might look and how it should be implemented. They then dump the spec or story on developers to estimate and implement.
In such cases, the customer requirements have already gone through a series of feedback loops before they ever reach the developer. By then, the developers have no idea what the original problem was; they only know what features the product owners have asked for.
In practice, you can see this when the acceptance criteria of a user story impose a particular technical implementation.
Imagine you are building an e-commerce platform. The product owner asks you to keep a history of the product prices. They don’t know how this will be presented to the user yet. But they expect to have some kind of list of prices, including the date when each price was changed, and a field with the current value.
When you ask how such a requirement will be validated during the acceptance meeting, they will tell you that the QA team will look up the product in the database and check if it has a price list and a current value attribute.
This user story is faulty on many levels: First of all, it does not bring any useful value to the user, since it’s a change in the backend that doesn’t impact the user experience. And secondly, the product owner imposes a specific way of solving this issue, and it might not be the best solution.
Instead of having an attribute for the current value and a list of prices, it’s sufficient to keep a single array containing the prices and the date, for example:
const prices = [{price: 16, date:”12-04-2020”}, {price: 15.99, date:”20-04-2020”}]
In the program, we could infer from the date of the price change that the latest price is the current one.
The above example described a simple situation. For more complex user stories, imposing technical solutions on developers will not only slow down the development team but will also introduce software design mistakes.
Most people think that specific engineering decisions cause bad software, when, in fact, it’s caused by poor software project management.
In my experience, software projects that fail proceed similarly: The product owner wants to build a particular solution without explicitly identifying the problem they are trying to solve.
For the very first iteration of the product, this might be expected. However, as the product matures, the product owner should have a clearer idea of the problem and work together with the team to find the appropriate solution.
Otherwise, this back-and-forth and shifting of features and requirements will either mean that the team will spend most of the time rebuilding stuff, or they will have to live with a legacy system of software decisions they adopted in the past that will eventually slow down the release of new features.
* * *
Developers might react differently to feature requests. Some might take the requirements and implement them exactly as described, no questions asked.
Others will start asking questions and inquiring about the context. Before beginning to implement the feature, they will first try to understand the underlying problem. And they will propose a different alternative to see what the product owner has already considered and why they decided to go one route and not another.
We’ll call this kind of developer a product engineer. These are individuals who combine a strong technical background with a thorough understanding of the business. They play a crucial role in perfecting the product.
As Sherif Mansour, a product manager at Atlassian, describes in his article on product engineers:
As a young discipline, we’ve spent a lot of time working out « how » to build software, and that’s a big focus in schools still. But once you have the foundations, you need devs who engage with the « why » actively. Engineers who have a thirst for using technologies to leapfrog human/user problems. Those with empathy to reach for magical experiences. That is what defined a product engineer in my books.... Bad product engineers cut too many corners, but great ones know that minimum lovable products need the right depth to be considered during the build phase.
Product engineers suggest different solutions, but they are also able to estimate feasibility quickly. A product engineer usually has a better grasp of the required effort of potential implementations. This allows them to consider many solutions quickly.
Maybe a product engineer will propose a solution a product owner discarded early on for fear that it would require too much effort. Perhaps a product owner didn’t even know the solution was a viable option.
* * *
At companies that build products for developers, you can’t miss product engineers. On my last team at Crate.io, the product was a distributed SQL database, and I had the chance to work alongside many competent product engineers. Our product owners knew how to harness their love for problem-solving in the product ideation phase.
These were engineers with vast knowledge and influence: Everyone came to them with questions. Of course, they didn’t have a fancy job title; they were simply called software engineers.
The point I’m making is not really about creating a fancy job description (though that might help). Passionate product engineers do exist, and their expertise is invaluable.
While good product owners have a natural ability to guide product vision, failing to utilize unique experiences and insights from product engineers is a waste of opportunity and talent.
A cross-functional collaboration will achieve the best results. The product engineer can provide insights on feasibility, usability, and security concerns; while the product owner can present the product vision: What features are on the pipeline and why?
Empowering product engineers is not only about giving them freedom over the code base and architecture, as Marty Cagan explains in this article:
Empowerment of an engineer means that you provide the engineers with the problem to solve, and the strategic context and they are able to leverage technology to figure out the best solution to the problem.
An easy way to tell whether you have empowered engineers or not is if the first time your engineers see a product idea is at sprint planning, you are clearly a feature team, and your engineers are not empowered in any meaningful sense.
I’ve long said that if you’re just using your engineers to code, you’re only getting about half their value.
This ensures that engineers are aligned with the product team and helps them understand the intention behind the product decisions.
For a product to be successful, team collaboration is essential: A lot of folks with different skills need to come together. Engineers should be encouraged to participate in the discussion early on. If they are not included, the product will suffer.
