Product Development Process

Generally, I think about three fundamental dimensions in product development: time, scope, and resourcing. You will never be able to force all three to your liking, in most cases you will pick two, w

Ideally you have the right market insights before you start building. However, if you have open questions, I encourage you to break down the project into smaller milestones you can ship that help you

Job number one is ensuring you have the right market insights to prioritize the roadmap correctly. Engineering managers and scrum masters can pick up the slack and keep the trains running on time when

“Agile Research” This is a term I coined to describe the act of always conducting user interviews. The problem with well-designed research projects is that they take too long and tend to deliver the i

At a high-level, I usually like to think about the somewhat simplistic delineation that PMs decide ‘what’ to build, while engineers deliver the ‘how’. Ultimately, prioritization comes back to thinkin

Generally, the engineering manager (EM) is more involved than the individual contributor (IC) engineers. First, before planning of individual features happen, I make sure the EM is involved and aligne

I’m a huge believer in transparency. Make your roadmap and decision process transparent. We use a weighted scoring algorithm where roadmap items (and ultimately supporting tickets) roll up into a prio

Engineers are part of your squad. They should be in the room for Problem Shaping, Live Prototyping, and Fresh Eyes. You should review your problem backlog regularly with your engineers and get their i

The first question I would ask is whether PM and engineering have aligned upfront on a mutually agreed-upon definition of the problem to be solved and the definition of success. In my experience, eng

This is a classic conundrum. The good news is it’s a lot less costly when it happens in today’s agile world than it was when I started my PM career in the days of 18 month waterfall development cycles

To answer this question, I’m going to put my PM hat on. Why is the engineer “rogue”? What is driving them to want to “slip in this feature”?  First, I’d talk to them, understand their frustrations,

Our product development lifecycle process looks very similar to a double diamond design process but with an adapted approach for our organization. While there are best practices for a product developm

I don’t believe in a universal end-to-end product development process. I believe there are key rituals and elements that should be present on every team to ensure great outcomes, but each team needs t

Work in the open. Create a culture on your team that encourages sharing unfinished work and working live together. This will drive the highest quality bar for your team. If you wait until the end of d

There is an interesting tension here between looking at problem spaces from a variety of angles to make sure you have a sound and differentiated strategy that is worth pursuing and inciting decision p

Product management is accountable and responsible for assessing which problems to tackle. But I strongly believe it works best when it’s a process where everyone can provide input, there’s transparenc

It is the Product Manager’s job to identify, prioritize and shape the problems the team is tackling. We’ll break this into two parts 1) finding problems 2) shaping problems. Finding Problems You nee

At the very beginning! It's so important to align on the why for any initiative. Why now? Why is it important? And a big part of that why is what the world will look like when you're ultimately very s

At the beginning of the project. Before we start implementation, I make sure to define:  What problem are we trying to solve and for whom? Why is this problem important to solve? What is the business

Our team believes that success metrics have the highest likelihood of driving focus and execution quality when they are tied to our strategy and something we consistently track and explore. Our teams

Metrics work best when they are continuously embedded into the process. We use OKRs, and cascade them down from top level corporate goals into product line metrics, product team metrics and sprint met

I generally like to break product problems into smaller, independent pieces to help me more effectively prioritize and isolate critical ‘must do’ work One potential way to approach a problem decompos

Ruthless prioritization. Many organizations are trying to do too many things given the capacity of their teams. I'd rather focus on fewer things that are likely to have a bigger impact than trying to

The biggest mistake companies make is treating product management a junior, technical function. A good PM is a strategic thinker who is market oriented. A big part in making that transition to the str

I’m a strong believer in product/feature teams owning their deliverables end to end, which includes not only product definition and development, but also testing and validation. This is even more imp

I recommend triangulation as much as is possible. Without a QA function, engineering should be checking to make sure from a technical standpoint that what they have built works. Product and design sho

The right PM to Eng ratio depends on a couple of different factors, many of which can from my perspective be boiled down to 1) the overall stage and scale of the company and 2) the nature of the prod

1:10 is what has been used as a rule of thumb in my experience. A PM wears many hats. If you don't have a program manager (pgm/tpm) 30% - 40% of the PM's time may be going into project management acti

Don't think there's a "right" ratio, but I would say 1 PM to 6-12 engineers is a good ratio. I think beyond 12 engineers, it gets a little difficult for a PM to stay on top of projects and the PM coul