C. Todd Lombardo

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 Miro or Mural) sometimes they hold design sessions and sometimes they just do it asynch. It could be a mix of the above, and it usually is.

I'll start with an upfront caveat - there is no one product development process. How you go about development will depend on what you want to develop: An entirely new product? A feature? An improvement on a feature? If I simplify - you need to: 1. Form a hypothesis on a problem that needs to be solved 2. Gather data and evidence that backup that hypothesis 3. Determine what data you would look at to know if you solved the problem and got the outcome you sought * User outcomes — How do you make the user or customer workflows better? Business Outcomes — How does this make money, save money or save time? 4. Ideate and find ways to validate a solution - whether that be via design prototypes, or in-market product experiments will depend on what you're looking to develop. 5. With a solution in mind, then you need to break it down into workable pieces of value. I favor the B.E.A.F. framework * Basic — What will simply solve the problem? * Enhanced — How can we improve on that solution? * Advanced — How can we expand the solution to more functionality? * Future — What would this looke like if we solvied it better than anyone? 6. Work with a dev team to break downthe work for the "B" 7. Check your measures to ensure you're driving to the desired outcomes (from #3) As always, your mileage may vary based on what you are developing. Start with First Principle thinking, it can take you far beyond any generic framework or process.

Communicate, communicate and communicate more! We have a quarterly product strategy meeting where the PMs share their plans and the execs ask questions ahead of the work being done, so there's time for the PMs to go back with the engineers and designers to refine based on any course corrections. We keep a set of artifacts available - a product roadmap and a product staraegy doc that have the details of what we're working on. We document a lot of our conversations in Notion and these are available for anyone in the company to read.

As soon as we start talking about the idea. PMs need to have a hypothesis about what a good outcome looks lie in the beginning. For example we were talking about some changes to our API recently and I asked if there was a way we could measure how many accounts change thier use of our API to include a particualr type of call and it turns out we have a bunsh of monitoring already in place!

Hm. There appears to be an undercurrent of "us vs them" in your question, maybe this is intentional, but look at your inner beliefs on that to see if there's a negative bias towards engineers. What control are you unwilling to give up? And why? First ask: What do you control and what do the engineers control? I think about it in terms of what questions do the players solve. * Product managers answer the why and the what: Why should we build this, and why now? What do we need to build? * Engineers answer the questions of how and when: How can we build this in a way that truly solves the problem and when can we realistically deliver it? * Don't forget those designers (my favorite players – Yes, I'm biased!) also play a role in answering the what and the how.

Ask them to repeat it back to you in their own words. "Explain it to me like I'm 10 years old!" Ask them where they have the most confidence and the least confidence about what they are delivering. Can they identify all the points of failure in their approach?

I've worked with some teams that have dedicated QA people and others with none. If QA falls solely on 1 person, this can also become a challenge where engineering is not checking along the way becuase the attitude is "Oh, QA will catch it" and this can create inefficiencies in your process. There's a saying, "if everyone is responsible, no one is." This sometimes happens regarding QA. Ultimately, I hold the product manager accountable for quality of the resulting product. If something isn't working, they have to prioritize and coordinate the work to make it right. To help combat this, PMs need to create the right amount of detail clearly answering "What does success look like?" ahead of code being written so that the engineering teams can check what they produce with the acceptance criteria.

I generally go by this guide * 7 to 10 engineers for every 1 designer * 1 product manager for every 7 to 10 "makers" (designers + engineers) It's never a hard and fast rule as every company is different. I find that B2C companies need more designers and PMs, but not always.

Two week iterations are very common and can work effectively if you've broken the work down in such a way that you're delivering customer value within each sprint. The question I have is: What does "on time" mean? If you're off by a day a week or even a month, that rarely matters. If yo'ure off by months (plural!) then you have not planned well. And yes, you need to plan. Nothing in Agile says don't plan. You also should have done your research. I'm a big fan of Jared Spool's approach - get the up front research right and the delivery will be fine. That's because you'll have mich higher confidence you're shipping the "right" product to solve the problem.

Name and shame them! (kidding) Look, these things may happen and sometimes they can be amazing, sometimes they're a waste. Ask youself why this happens? Do they see a need you're not addressing? Do they want to showcase their skills? Or is it something else? If you build trust with your engineers, they'll tell you what they're doing and why. If you don't have that trust that's likely why the secrecy happens.