Product is the what. Engineering and Design are the how.

There's a problem I see more and more in companies, where Product is thrust into the role of "supervising" Engineering. This is not actually their demesne and will cause friction in the end. Engineering is accountable for development, testing, deployment, and reliability. Product is accountable for product research, direction and definition.

That supervisory relationship leads to a common practice that is a big issue: Leashing all engineering artifacts to the product definition means that technical concerns are subsumed by the roadmap as Product sees it. Tech debt will go unaddressed or will be created without limit, and purely technical problems like infrastructure will have to be laboriously explained in non-technical terms to proceed so they can be prioritized by Product, leading to a slowdown.

Purely Product-led initiatives result in wasted time and work.

What’s my evidence for this approach? Look at Microsoft Office as a model for the pure Product-Led ecosystem. For years under Ballmer customer sentiment around Microsoft’s products suffered from low customer engagement and a feeling that they were “stagnating.” Yes, you’re right, Microsoft is one of the largest and most successful companies out there and was even with flagging sentiment. 

But during that time Google Docs, Dropbox, and Box carved out chunks of their dominance that should have been impossible. Microsoft’s product teams without a doubt released more features into each of their products and shipped more bugfixes, probably by an order of magnitude than at any time in the company’s history and far more than the upstarts. 

This culminated in Sharepoint. Sharepoint was the ultimate in file sharing systems, with configurability and control unmatched by its competitors even today. But it was beat so handily by less-capable upstarts that Microsoft had to pare it back and release OneDrive.

• Word can do more than Docs.
• Excel can do more than Sheets.
• Sharepoint can do more than Dropbox, Box, and Google Drive combined.
• Outlook can do more than GMail.
• Active Directory can do more than GSuite admin.

But which one do people use? And why? GSuite, because GSuite feels like a system and at that time, Office felt like a collection of unrelated and confusing features.

By the numbers, Microsoft was far more innovative, and they could prove it to you in an argument if you bought into the idea that more features = more innovation. But popular sentiment was that Google was more innovative by far, and Google ended up creating a beachhead on Microsoft's shore that should have been impossible.

Engineering, Design, and Product are a collaborative separation of concerns.

When facing the problem of "Product running the show" at his workplace, an old colleague said this:

The way that I read it was that Product creates the initiatives with their requirements and acceptance criteria.  I then feel that it is the engineering managers responsibility to force in the technical debt to be worked on.

The problem here is in the word "force"  That's one way to do it, but every time you have folks address technical concerns, your making of room for them will use social capital. 

The other way to approach it is to say that "These are the engineering standards we hold ourselves to," and bring that to the table and have Product agree to them. Then you can label or tag or whatever tickets that are aimed at keeping the product we're building in-line with our standards of excellence.

If you want to put them in the product definition as well because that's where initiatives live, then great and do that. If you do it that way, the negotiation has been done up front and it's one expenditure of social capital aimed at a productive collaboration everyone can agree. The other choice is negotiating each time for time and resources against what Product sees as furthering the product in the eyes of consumers.

Look at it this way. Every product you build has infrastructure requirements, and they almost never have direct input from Product because the average product manager knows zero about infrastructure and security.

If Product ran your infrastructure project as its initiative, you'd debate the merits of terraform and kubernetes vs. just running on something "quick and dirty" because the quick and dirty will get product in front of customers and you can always work on reliability as a "fast follow."  Forget spending the time and energy selecting a queueing technology. You'll just do the queue in postgres because everyone knows it and we can get it out there faster than SQS.

You have to have standards and goals in engineering that are just as "top level" as the product roadmap, because if you don't, everything is an MVP discussion and you throw necessary things out that will bite everyone in the end because you didn't feel like you had the capital to negotiate and "this one thing" didn't seem that bad to compromise on.

Engineering and Design make products flow naturally.

So my thesis here is that if people in Engineering and Design come up with standards for their projects and hold these at the same level as Product initiatives, and then product, design, and engineering collaborate on a shared vision of development, we will drive innovation far further than Product alone will and we will do it with lower cost and fewer R&D resources. The ideal here is not just a "definition of Done" but a "definition of well done." The right feature, inserted in the right place, and designed for the people who are meant to use it.

By agreeing to these standards up front, you put Engineering and Designers on an even playing field with Product. Giving engineering and design the mandate to make everything you build a part of your users' natural workflow, you can develop fewer features and still gain ground faster, and you can do it with less friction. 

Engineering and Design functions should systematize the Product definition. If you build feature after feature and rely solely on customer education or product marketing for uptake of those features, the majority of those features will go unused by most people. Users don't get exposed to product marketing every day. They are exposed to your product every day. Users don't click on marketing emails every time they arrive. They do move through their primary workflows in your product every time they open it.

Careful engineers and designers, given reign to do so, can take feature requirements in a product definition and fit them into those workflows so that they improve them as a matter of course.

Every feature that has a thesis about its use built into the natural workflow of the system will benefit your product in terms of NPS, stickiness, and customer sentiment. Cross-sells will be easier because asking people to learn a new product means they only have to tell their department to learn the bits that are specific to that product’s function, not re-learn how to send a message, add a user, create a calendar appointment, create a form, or design a report or a chart. 

It takes longer to launch a product that complies with SRE’s standards for reliability and security. It takes longer to build a product that fits your design system. And it will take longer to launch products that comply with an engineering system. But if every feature lands with customers, you can build fewer features and still give your customers joy.

Cohesiveness strengthens your brand.