← Back

Product Engineering: From 'Scrum' to collaborative product roadmaps

As Senior engineers working on often high impact, important services in a large organisation we can easily become detached; sidetracked and blinded from the real user outcomes we really want to create, carried along with the ceremony and performance that surrounds us as engineers. It threatens to hi-jack our sense of value as engineers - doers, solvers - and our primary asset and means of producing valuable output; our focus.

Process-heavy methods of agile, implemented as scrum, are optimised for predictability and visibility. It traps engineers in the performative culture it promotes, and can frustrate us reaching flow state; working to build the right things using an understanding of the product combined with user feedback and data, and then as professionals, connect autonomously across the business; self-organising in a lean tight working-group on the next-right-things to build.

Process-heavy frameworks and agile-as-scrum threatens to abstracts away the real driver of the business we’re in; that is discovering and doing what is valuable to customers and not do… what is not to that end.

‘Scrum’ masquerading as agility, can easily distract developers and compel compliance with its groupthink; its licence to fabricate a worldview of what *represents value; as a controlable metric for success. Don't like the story the map tells? Make a new map!

I observe Scrum not only used to give the facade of Agile, but used as a means to synthesise its own reality; more favourable and easier to quantify than actual value, which is then reported and sold to stakeholders via outputs: charters, definitions, up-front planning documents, risk assessment, long-range planning, collaborative boards and a packed calendar full of ceremonies with large invite lists. Look; we’re Agile.

This is cargo-cult agility and ignores the spirit of agile in valuable user outcomes.

Process-heavy scrum at the team level within a larger organizational structure, diminishes the direct connection to market signals and users, leading to under-utilisation of engineers.

I feel because such direct connection is a more conveniently nebulous but critical measure of what the market - our users - respond to as valuable.

This leverages a troubling cognitive dissonance on developers who are intrinsically motivated to create meaningful work for users, rather than backlogs, predictability, and processes which attempts to reduce an emergent, creative process of discovery-by-doing to a waterfall structure. Yet engineers know we are learning what makes sense but can only know by starting.

We need only consider the practice of estimating and refining technical features when we know least, as we don’t start learning until we start building.

My observations aside, and amid the general emergence of this movement in the industry I feel there’s an answer; a reckoning. Leaner teams, comprising empowered, product and user-focused engineers.

Product Engineers

The future of software product development I discovered might be in a new-to-me concept I discovered on Jordan Cutlers’ Substack High Growth Engineer - Becoming a Product Engineer (ignoring regrettable use of ‘rockstar’) and Posthog.io have an awesome description of the role and why it matters to companies moving from project to product mindsets.

Product Engineering is about full-life-cycle involvement in the iteration of a product, based on user feedback and data to know what problems to solve.

The article gives a model which I feel represents a vision for the necessary organisational shift toward small, focused, empowered product engineers.

Engineers here take initiative and are enabled to have ownership of the end-to-end lifecycle from identifying the user and business needs with highest ROI, to development, testing and iteration based on feedback.

What makes them unique is their focus on creating a product for users. They care about building a solution to problems that provides value to users. They must be empathetic to users, and this means caring about user feedback and usage data.

Instead of perpetuating the traditional software lifecycle in a ‘project-oriented’ paradigm, we might as aspiring PEs, ask:

1. “What is the user’s actual problem?”
2. “What is the best solution for the user?”

As such, Product Engineers are heavily invested in market and user feedback. They are ‘customer obsessed’ and are opinionated about the roadmap for the product, building a deep understanding of the problem space, and then self-organise to build and iterate solutions.

"As a product engineer, writing code is just one part of [the] job. Product Engineers also talk to users, get involved with design, and _develop an opinion_ on what needs to exist in the world. Then you'll move with urgency to make it happen." - Kushal Byatnal via Joe Albanese

The primary goal of the Product Engineer then - is in a more direct way than typically mandated in feature teams - about building a great user experience and code we write as mere means.

With increasing efficiency in software development possible, market competition and lean startups without legacy structures, the role of the Product Engineer seems a natural step in the evolution of the role of Software Engineers; a way in which Engineers can have more impact; enhancing their technical and product knowledge, with market feedback and enablement at the strategic level.

Product Engineers can provide valuable, informed recommendations about technical trade-offs to stakeholders on the product roadmap and be empowered to prioritise what is valuable.

This is exciting to me, as many like me as Senior Engineers will have developed the commercial skills necessary to be successful in what could be a new frontier of software delivery; an alternative to the parallel tracks of Tech or Management the industry has standardised.

No longer feature-teams

While start-ups and product-led companies are adopting this approach, we may soon witness a fast-following among established product companies wishing to build a strong Product culture.

The question is whether larger orgs can be honest with themselves; not paying lip service to true engineer-empowerment and product-market fit excellence, but structuring in such a way as to separate these teams from the legacy funding model and make it possible; to unlock small *Product Engineering teams, empowered* to progressively own more of the product at first.

To facilitate PEs, the goal is to minimise the centralised processes that stifle scrum feature-teams in larger orgs and empower teams with a maker’s schedule – to make decisions, prototype and build what matters.

I feel companies adopting and hiring accordingly for this mindset would see a significant strategic advantage in product quality, market-fit and engineering engagement.

Where we are…

Let’s be real though. Many of us are maintainers; working with functioning processes, entrenched incentive structures, and mature codebases with a long list of project features to implement.

But there’s much we can take and aspire to even as individual contributors. We can stand out as acting Product Engineers in our feature teams as far as we’re able.

We are product experts, with the technical background. We are then, uniquely positioned - obliged even - to communcicate technical trade-offs, advocate for users and doing the right things in light of user feedback and data.

But surely they need direction; to keep the product roadmap coherent.

In a recent episode of Lenny’s podcast, Dylan Field, co-founder of Figma, discussed the role of Product Management, especially within Figma:

...effective PMs communicate and define the strategic framework; scoping the range of options for PEs to work within, to which they can bring their own deep technical and product knowledge to deliver the outcomes that are valuable.

In an organisation entrenched in large-scale ‘agile’, small teams must protect their goal of delivering autonomously from the surrounding process-oriented environment.

I took some great inspiration and assurance in the value of what I can bring to a product’s direction; a benchmark for how I’m still able to impact a product as an individual contributor, and encourage others in my team to think beyond where engineers might feel they can have influence.

As Engineers we must communicate and protect our principles and standards as it’s our responsibility to educate stakeholders of their importance for product quality and team health.

If we establish trust we don’t need permission to do the right things* as Dave Farley of Continuous Delivery reminds us.

The Product Engineering lens of Software engineers, I believe represents the future of what product companies will need from engineers to remain competitive and leverage the expertise and user-focus of engineers; the thing which motivates us: Solving problems, building things that matter and making advocates of users!