What activities do you include engineering in when working through problem statements?

tl;dr: Engineering should be involved from the start—because in an AI-native world, the distinction between roles is breaking down. What’s changing: Roles are converging into “product builders.”The traditional split (PM defines, Design designs, Engineering builds) is collapsing.Teams are increasingly made up of generalists who can go from problem → solution → implementation. Context replaces handoffs.Speed and quality now depend on everyone having full context, not clean role boundaries.If engin ...Read More

I involve engineering and design right from the start, not just at execution. When we’re defining the problem space, I like to bring the team in to align on: Who are the customers? What are their pain points? How are we solving those? What data do we have (qual, quant, comp) to validate that this is a real problem? This helps build context early and creates shared ownership from the start. I also pull in engineering for early brainstorming. Some of the most creative and efficient solutions I’ve ...Read More

Engineering is a key partner in any product development organization and, as such, should be in the box with you, thinking about the problem statements impacting your customer. I always like to include my Eng partners in problem definition as early as possible; it fosters a customer-centric dev squad and promotes collaboration early in the process of developing a new feature or product. Here are some activities that I find are non-negotiable activities that you should include your Eng partners i ...Read More

Engineering should be involved from the beginning. Not just to scope or estimate, but to shape the problem and bring technical insight into the discovery process. Here’s how I typically include engineers: Problem framing. Engineers are part of defining the problem, not just reacting to it. We review customer pain, look at data, and align on what we’re solving before discussing solutions. Research and customer insights. If we’re doing customer interviews, engineers are invited to join. Hearing th ...Read More

We have something we call a "common roadmap discovery doc" that has a set of questions around the problem that the PM, the designer and a tech lead (engineer) all work on together. The doc has questions about the problem to solve, the evidence we have around why it's important, the technical challenges involved, and what design constraints should be considered before choosing a particular solution. The surrounding activities differ from team to team. Sometimes they hold virtual workshops (think ...Read More

Engineering needs clear context on why a problem matters - its root cause and its business impact. The timing of their involvement depends on their availability and the problem’s scope and priority.I keep engineers loosely informed as problem statements come up as they often spot technical insights early that can save time. For example, what seems like a UX issue might stem from a synchronous backend process.Deeper involvement usually comes once priorities are clear and the story / PRD for the s ...Read More