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, which in turn determine the third: * If you have a team with a given size and you pick a ‘ship date’, you are implicitly making the decision that scope needs to be flexible (i.e., you will have to be OK cutting / adjusting what is getting shipped) * If you have a team setup and a clear scope in mind, the time component will be determined based on bottoms-up p...

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 answer those questions. This way, you are continually shipping, but they are smaller in scope, but also helps you de-risk when there's a lack of clarity in market insights. 

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 you’re falling behind on customer research. Never shortchange market insights!

“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 insights after you’ve started building the thing. Advocate for a “rolling recruit” of your key personas so that you can tap into talking to users *every week.* This ensures you have feedback and insight in the moment you need it most before the product is built and decisions are made. Alternatively, you can create a type of Customer Advisory Board where members opt into research questions, prov...

* 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 thinking about the ‘return on an engineering investment’. PMs provide the ‘return’ (i.e., user value), engineers help size the necessary investment. No feature can ever be properly prioritized without both sides of this equation. * Getting buy-in from engineering usually comes from a deeper involvement and collaboration of engineering and PM as part of roadmap and prioritizatio...

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 aligned when we are creating the product strategy of our team. Doing this makes getting alignment on individual features much easier because the engineering team knows what the higher level goals are and why we are going after those goals. I've found that in order to get buy in with engineering, I have to make sure the team understands why the work they are doing is important - how it ladders up to a...

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 prioritization rubrik. That prioritization methodology should be available to anyone in your company, including engineers. Make grooming a collaborative activity - let them weigh in on the scores you are giving to specific tickets. Argue with fact, not opinion. If you’re doing your job you will have the best market insight and can fall back and cite your customer research. Generally that’s going to...

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 input and feedback. —Influence is the curiosity to get to the best solution— and engineers will undoubtedly think about things differently than you - leverage this to find the biggest problems and get to the best solutions. More about influence here: https://medium.com/@lizzymasotta/product-management-is-not-about-influence-e3004c12f44f

* 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, engineers don’t just slip in features for no reason, but there might be other failure modes upstream of that decision. It’s important to understand the ‘why’ and adjust processes and behaviors accordingly. * Here are some typical examples of friction points I’ve seen in the past and how to potentially address them: * Disagreement on overall roadmap prioritization: take a s...

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. First, apply your PM skills and dig in and explore the problem and its root causes. Is this an isolated issue specific to a single engineer, or more of a systemic cultural issue? If it’s the former, the fix is a bit easier. Make sure you have a rock solid relationship with your engineering managers and address it with them. Any EM worth their salt knows the cost of unplanned work, and it’s...

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”?  1. First, I’d talk to them, understand their frustrations, and where they’re coming from. 2. From that conversation, I would expect to learn a bunch of stuff I probably didn’t realize about how frustrating it is to build in our codebase. The engineers and designers on your team are a key persona you must also serve as a PM. If you can make their lives better, easier, more efficient – do it. 3. Then, I'd come up with a plan to mak...

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 development processes, I've found that there is a decent amount of adaptation and adjustment that needs to happen to customize an approach for the needs of the organization. I've not seen 2 product lifecycles that are the same.  At a minimum, a product development process should help reduce friction for the R&D teams, create clarity around what we need to know before we invest, and insight into the ...

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 to tailor the development process to their unique situation. My must-have product development elements & rituals: 1. Common Language - Your company should have a common language for the product development process. This is not a prescribed way to do product development for every team at the company (this needs to vary team by team for good reason). At Shopify, we call it GSD...

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 development to QA too many problems will be compounded. Some rituals I use to encourage a high quality b ar throughout the entire product development lifecycle: 1. Fresh Eyes - Once a week anyone in the Product Squad can demo unfinished work for the purpose of getting feedback mid-build. The phrase and concept of “Fresh Eyes” comes from Shopify - it’s part of their culture to value ...

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 paralysis by having too many individuals involved in the process. And the truth is, it depends on the project. I’ll give you a couple of examples for how we have tried to simplify the investment of time and talent for this particular challenge, but it may not work for all organizations. The approaches we take have to be at least a little malleable for the organization or adoption and usefulness ...

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 transparency on how decisions are being made (see question on feature planning), and where decisions are made based on market fact - not opinion. Any debate should be decided by data and market (customer) signal. As a PM, your market intelligence should come from as many sources as possible. Customers, partners, analysts, customer success, sales reps, sales engineers and even engineers. Entertain as ma...

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 need to have ongoing sources that you’re plugged into to find problems. Common sources are 1) customer research 2) exec requests 3) support tickets or user feedback 4) product usage data. In my experience, I’ve found the most fruitful source of problems and opportunities is customer research. Be careful with exec requests - the common behavior is to blindly execute on them. You must ask quest...

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 successful. To bring that to light, I usually define 1) a success metric -- the one thing we're going to focus on moving and 2) the health metrics -- what we need to watch to make sure that we aren't tanking another key metric with our project.  The more invested you can get the folks you work with in what success looks like and why you're doing the project, the more buy-in you'll have. Never...

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 impact?  * How does this project ladder up to the broader product/company strategy? * How will we measure success? 

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 are well versed in our strategy and the related metrics we are trying to move. We, therefore, set our success metrics early in our opportunity assessment phase. We maintain flexibility and will adjust as necessary if new information surfaces throughout our product development lifecycle that suggests we should select different metrics. We bring engineering team leads into the process early. A...

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 metrics. Use them in a regular cadence to assess progress towards high level strategic objectives. We continually refer to them, in quarterly business reviews, sprint retrospectives, grooming and planning.

* 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 decomposition like this is to think of three distinct categories of feature work: a) items that are crucial to achieve your overall product goals (clear ‘must do’) b) ‘critical path’ dependencies that can block success/completion and c) things that are nice-to-have or could benefit from additional trade-off discussions (these are usually where you will gain most flexibility in...

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 accomplish a larger number of them less well and with less impact to the business and the customer experience. 

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 strategic is learning to speak in terms of business outcomes, and learning how to sell internally. If you’re not getting the resources you need, put together a model for the business benefit you could drive with more resources. Don’t talk about story points, or feature velocity, or any of that. Executives and finance people don’t understand it and don’t care. Talk about revenue growth accelerat...

* 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 important in an early-stage environment, where moving quickly means engineers will need to make game-time design decisions day-in and day-out. * Eng and PM should collaborate closely to ensure the quality of the feature being worked on. * I recommend engineers incorporate testing as part of their development cycle (and test before they release, incl. all relevant edge case...

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 should also be checking to make sure that the experience you have been cultivating is going to create the positive experience for your customers you intend. I prefer to have each of the functions check to make sure we are shipping quality.  The most important thing is that QA happens when development is done. And if any changes to the code occur that they are also QA'd. Which sprint it happens ...

* 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 product you are working on. Given those dependencies, it also makes sense to revisit this decision at key turning points of your product (or company). * Practically speaking, the traditional ‘2 pizza box team’ of 8-10 engineers per PM is a decent baseline to start with. Here are a few example considerations of how I would think about adjusting this ratio for individual teams...

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 activities and you may need an extra PM (or your first TPM) You may be supplementing other functions in the org: marketing, sales, solution consulting, BD. The point here is to assess what are the org needs and what role PM is playing or ought to be playing. It might not be a matter of how many PMs to Eng ratio. How would an extra PM accelerate the busines? If you were the CEO how would you best in...

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 could become a bottlenect to project progress. I would also say 1 designer to 6-12 engineers is a good rule of thumb.