The purpose of this post is to boil the topic down to its most critical points. Much will be left out, and much will be simplified.
Ensuring your team is building the right thing is the core purpose of the Product Manager. Everything else is secondary or in support of this purpose.
The team’s ‘cycle’ of work has two phases: Discovery, where you figure out what you should build, and Build, where you build it.
These phases should run on ‘dual tracks’. A PM should be running a discovery cycle while the engineers are building, so you’re ready to start the next build cycle.
Discovering what your users want is the main activity of the Product Manager. You need to build empathy with your users.
The engineers rely on you to tell them what the customers want, what is valuable to them, what they think, and how they will act. This is difficult, because you have many users who think differently, and because they themselves don’t know what they want.
You must be talking to a range of users, frequently, and in a range of contexts. Some of these should be conversations, without specific outcomes in mind. Some should be highly targeted, with specific questions. Write down what your learn.
Never take what users say at face value. Users know what their problems are, but they are terrible at proposing solutions to their own problems. If you build what users ask you to, you will build the wrong thing. The hedge against this is to constantly dig beneath what the users ask for. Ask why they want what they say they want. Ask it many times in many different ways.
Talking to users is not scalable. Data is. Data shows what people do, not what they say they’ll do. But you can easily make incorrect assumptions about what data means. Treat any insights you get from data as hypotheses, and find ways to test them.
When you have a good sense of the user’s problems, you need to get the work ready for the the engineers, by building a package (or PRD, Pitch, Bet, Spec) for them. Whatever the implementation, keep in mind the goal of the package is to familiarize the engineers with the situation so that they can design something to solve the problem. The package should have the following characteristics and content.
The content also makes it useful for making prioritization decisions between different problems.
The relationship between PMs and Engineers has a huge impact on how effectively your team will deliver value. There needs to be mutual trust, respect, and credibility.
The goal of the PM in the build phase is to enable the engineers to effectively build. This means getting them things that they need to do that, and getting anything that isn’t that out of their way.
Engineers build best when they can focus on a single thing for a full day without interruption. Organizations create a lot of noise, distraction and admin work. The PM must keep this noise away from the developers, and not contribute to the noise by creating unnecessary admin overhead.
The PM should create a frequent, usually daily, feedback loop so that engineers can share what they’re doing, get feedback either from other developers or the PM, and make quickly make course corrections.
Software projects are inherently complex. They need to react to changing circumstances and knowledge. Estimates will change constantly. Responding to this apparent chaos with a tight structure is attractive, but it will choke a project, inhibit delivery, and lead to engineers feeling micromanaged and stifled.
However, letting the chaos reign invites scope-creep, rabbit holes, and lack of coordination, all of which threaten delivery. The team needs enough structure to keep engineers focused without inhibiting delivery. The PM should provide this loose structure. It is a delicate balancing act.
An engineer should always be clear what the definition of done is for the task they are doing. If they don’t have this, they will spin. They should always be aware of how that task they are doing connects to a broader goal. This allows focus within the task, guiding implementation, and allows the engineer to select their next task in a decentralized but still coordinated way.
Make sure there are several ‘levels’ of goals, which can each provide context for the levels on either side of it. Define clear cycles of work, with defined outcomes. The cycle length, and how they are implemented, depends on what works for the team and the situation. Start with something, then iterate.
Every delivery is the start of a new discovery cycle. You need to be ready to get feedback on what you delivered. What new user insights can you get from what you’ve just delivered? How are you measuring how effectively what you’ve delivered achieved meets the intended outcomes? What do the users think of it? What are the unanticipated outcomes? You should have a plan in place for establishing all of this before you deliver the build.