Is Your Team a Cost Centre Without Product Understanding?
How to discover and address a engineering x product divorce
Today’s issue of Crafting Tech Teams covers topics following a theme of symptoms, product and engineering value streams and maintaining a strong product culture:
The Importance of Product Understanding. Imagine sending your engineering team on vacation. See how soon you get to market. Now imagine sending the product team and any product-oriented founders. How much revenue are you making next quarter? These aren’t two departments.
Identifying Signs of a Cost Centre Mentality. Teams can get stuck in cost centre mentality for so long that they make it a habit. At its extreme it becomes company culture. Learn to identify the signs.
Shifting Mindsets: From Cost Centre to Value Creator. Number one priority is creating value. More value. Contributing to value streams. Enabling value streams. Capturing revenue from value streams. The big money will follow your biggest value stream.
Measuring Success: KPIs for Product Understanding. When the engineers get their first taste of product data, they will develop a hunger for it. Good. Now automate that feedback loop!
The Importance of Product Understanding
Product understanding is foundational for successful engineering teams. It goes beyond technical expertise, empowering engineers to align with customer needs and business goals.
When engineers grasp the product's vision, they are no longer bound to meeting-oriented back and forth. Product and engineering are skills axes of knowledge that each member of the team balances individually. The product owner occupies a position that complements the tech lead, rather than acting as a source of feature requests.
"The most valuable asset in the software industry is the synthesis of programming skill and deep context in the business problem domain, in one skull."
What most business owners miss is that building an MVP is easy. Delivering on quarterly roadmap goals is easy. The valuable, hard problems demand 12 months of intense, high-density and domain-specific communication within the entire team adjacent to customers’ needs.
There is no replacement for this and it cannot be solved with commodity product planning as can with commoditised MVPs. Often, agencies give a false hope and promise a commodities, smooth go-to-market with super-profitable growth strategies. In reality, most try to deliver a commoditised engineering experience with no deep product understanding.
If you want your tech, web, SaaS, AI business to succeed then get engineering team to truly understand how the product provides value to customers and what pains they address. An empowered, knowledgeable team can move mountains. An isolated team becomes a cost centre—a feature factory.
Identifying Red Flags of a Cost Centre Mentality
A cost centre mentality can inadvertently hinder the growth and potential of engineering teams. It manifests in various ways, such as an overemphasis on budget constraints, a reluctance to invest in professional development, and a focus on cost reduction over value creation.
Most Common Red Flag: No planning, terminology or context about value creation. All the tickets, stories, plans, specs are about “feature completeness” and “cost reduction”.
Planning alternatives routes for delivering 100 different features. A product-oriented profit centre focuses on 100 different ways to improve a single feature. Especially the core one. This is especially cumbersome for startups and businesses that are cash-flow negative. You can have all the features you want adjacent to the core offering once value creation has been established. But until then, this is rat-race towards bankruptcy.
The engineering team is spread too thin. Each quarter, new customers segments are acquired that only use the newest features. This requires a constant effort to maintain years-worth of competing, orthogonal functionality. I haven’t seen a business capable of handling such increase in complexity without increasing their head count exponentially year over year.
Lack of Equality Between Tech Lead and Product Lead. Two competing types of decisions need to be made: coming up with more feature improvements, fresh ideas and eliminating as many of them as possible. It is crucial that the person who is deciding “more features!” is not also making decisions on “cut scope now!”. These two people need to be highly respected peers on equal footing.
Cannot Celebrate their Successes. I survey a lot of teams during my coaching work and one of the most common root causes for low motivation and ownership is that they cannot relax. They never celebrate. There are multiple reasons for this: success wasn’t defined. There’s always more work and deadlines are optimised for process metrics, rather than outcomes.
As a caveat to the VPPE point: I have seen a few successful VPs Product and Engineering, in one person. But that’s maybe 1 in 100 organizations, and at that it only works in a heavily productised single-feature business.
Shifting Mindsets: From Cost Centre to Value Creator
Help your team understand how their contributions directly impact the organization's bottom line and overall success.
You can achieve this by interrupting the never-stopping flow of feature production and create space for product inquiry, inspection and customer feedback.
The problem is obvious and the solution nerve-racking. After long periods of constant feature-producing activity everyone is terrified of stopping the line. Yet, stopping the line is one of the fastest ways to adjustment, learning and quality improvements according to Lean.
P.S.: September’s book club is about Lean Software Development!
Shift the focus from merely completing tasks to understanding the end-users' needs and pain points. Encourage engineers to view their work through the lens of the customer, which can inspire innovative solutions and foster a customer-centric approach to product development.
User Stories are not enough for this. In fact, I’d urge you to abolish User Stories altogether and adopt a BDD-style written communication. Rather than isolating your product experts to JIRA or similar tool, have them pair or ensemble with engineers to write acceptance and behavior criteria. Directly code, write tests or compilable instruction documents. Bypass the unnecessary busywork of writing tickets, stories, epics, then having the engineering team struggle to split them into smaller pieces and making up fantasies about how long they would take in a parallel universe.
*sigh* / rant over
We’ll explore BDD/TDD in a later issue in combination with SPACE metrics and event modeling as a project management technique. Now let’s look at KPIs.
Measuring Success: KPIs for Product Understanding
Quantifying the impact of product understanding on your team's performance can be challenging. The KPIs below are in no particular order. Get inspired, use any you like and make up your own. Use these as a guideline of what could be measure.
Feature Adoption Rate: The team needs FAST feedback if a feature is not being used. Primarily so they have data that it is safe to remove. That will be the major scenario for most of these. Do not confuse this with customer analytics. This is about verifying assumptions of how useful / important a feature will be.
Innovation Contributions: Evaluate the number and impact of innovative ideas generated by your team members. Combine personal career development and individual quarterly goals so they complement the team’s OKRs. Is someone spearheading a code health initiative? Adopting a new technology? Replacing something with old, stable tech? Have them own that knowledge bubble and share it on tech talks and internal meetings. Back when I was at D. Labs and FirstBlood, we had internal tech talks and architecture inspiration meetings every week.
Estimate Value and Revenue: Estimations of effort require to build a feature is one side of the coin. The other is understanding the potential range of created value to existing and new users. The question I start each engagement with a new team is “Who can explain to me how you make money?”. “How are your users delighted or make more money by using your product?”. They usually don’t know. Sometimes nobody knows.
Customer Feedback Incorporation: Measure how effectively customer feedback is incorporated into product improvements. A team that understands the product takes user feedback seriously and integrates it into future development cycles, ensuring that the product evolves to meet customer needs.
Training and Upskilling Participation: Monitor the participation and success rates of team members in product-focused training programs and workshops. High engagement in such initiatives demonstrates a team's commitment to enhancing their product understanding and keeping up with industry trends.
What did I miss? Which ones would you add to the list?