A primer on product management for engineers

Breaking down the basics and benefits for engineers looking to manage product development with precision and verve.
Part of
Issue 19 November 2021


You’ve got an idea for an amazing product. Sure, you could just start building—but a proper product management plan, scaled to suit your project, will help you do so more effectively and efficiently. 

If your company is too early-stage to have a product manager or product team, or you’re building an internal tool, personal project, or something your company doesn’t think requires product input, you can still leverage some lightweight but potent techniques to reap the rewards of product management.

What is product management?

First things first: Product management is the practice of managing the life cycle of your product. Many engineers see product management and agile product development—the daily rituals we all know and, er, have feelings about—as synonymous, but the latter is more like a facet of the former. Think of product management as the glue that unites your customers, the business, design, and engineering, ensuring the product you build meets your customers’ needs, is salable, and ships on time and on budget. 

Product managers execute the functions of product management, such as conducting customer research to gather user requirements. They plan and prioritize how to build those requirements, factoring in design and engineering expertise and constraints and analyzing the outputs and outcomes of the development process to identify ways to optimize. Most importantly, they ensure the customer’s voice is heard throughout the development process. If you don’t have a product manager on your project, this is your job.

Why product manage? (Or, everything is a product)

If someone is going to use the thing you’re building, it’s a product. And if it’s a product, it will benefit from product management. 

Whether it’s public-facing, an internal tool, or a personal product, every project has customers (or at least a customer—you) from whom you can gather and document user requirements. Understanding and tracking those requirements, and building the right combination of features as a result, is key to your product’s success. Product management procedures allow you to capture these requirements in a regimented way that will help you plan and structure development.

If you’re working on something small or more personal, treating projects as products can be a compelling way to manage your work. I often go weeks or months between working on specific projects, and using essential PM frameworks means I don’t have to rely on memory to recall what I’d planned to work on next. Instead, I have a ready reference in the form of Jira tickets, GitHub issues, or a line in a note-taking app. 

Product management processes can also enrich collaboration between developers. Many internal or open-source tools, for example, are built and deployed by small teams of engineers. Establishing protocols that delineate what you’re building and how you plan to go about it makes it easier for new folks to contribute.

How do I do product management?

Now, let’s walk through a lightweight version of what full-fledged product management looks like. This framework for surfacing and tracking requirements, prioritizing those requirements, and building the product can help you implement its key tenets in a straightforward but methodical way.

Surfacing what users want

The first step is to document your understanding of what you want to build. Particularly on small teams, this often lives in the heads of individual engineers. Documenting requirements renders the development process more open and transparent. This makes it easier for new engineers to participate and, if shared externally, provides users with a clear picture of the project.

I’ve found user stories to be the easiest way to track requirements. Each user story focuses on an action a user wants to take; in combination, they paint a picture of the product as a whole in a way that allows you to prioritize, sort, and track the overall state of development. These stories are recorded in a backlog and become the list of things you need to deliver to make your product successful.

Here are some example stories for an imaginary product called AmazingWidget:

  • As a user, I want to create a collection of the widgets I own.

  • As a user, I want to delete widgets from my collection.

  • As a user, I want to export my list of widgets to a CSV file.

A user story can be as detailed as a field-by-field specification or as simple as a single sentence, and you can dial the detail up and down as needed. I recommend starting with a simple template:

  • Title: A one-line summary of the user story.

  • Priority: How important or urgent is the requirement? (I categorize priority as low, medium, or high.)

  • Effort: How much work will the requirement involve? (Again, you can specify a spectrum like low, medium, or high.)

  • Description: A one- or two-paragraph description of the requirement.

If you don’t know what people want from your product, start by asking potential users a small set of questions aimed at understanding their preferences. You don’t need fancy tools to do this; most social media platforms support polls, or you can create surveys using applications like Google Forms. Many survey tools, as well as product management software like Airtable, pipe directly into spreadsheets or other systems you can use to record requirements. 

After you’ve collected feedback, you can use a ticketing system to document the resulting tasks. GitHub projects have issues available out of the box, and applications like Trello and productivity software like Asana are also good options for tracking issues. Of course, you can also leverage any product management tools your organization uses.

Backlogs and prioritization

With your user stories in hand, you should have a solid idea of what you want to build. Now it’s time to figure out how to get started. 

Whether you’re working solo or within a larger organization, it’s unlikely you’ll have the resources to work on every aspect of your product at once. You’ll need to prioritize and estimate your backlog. There are numerous ways to do this, but I’m partial to 2x2 grids, which measure impact like so:

“Impact” refers to how much a feature or requirement will improve the product. “Effort” is the amount of work needed to build it. Impact can also indicate mandatory features—for example, authentication might be high-impact because it’s required and you can’t ship without it. 

The grid will help you determine which tasks to prioritize, starting with the top-left quadrant and ending with the bottom-right:

  1. High impact, low effort: Critical features or requirements.

  2. High impact, high effort: Tasks you should break down into smaller stories and move to the first quadrant.

  3. Low impact, low effort: Nice-to-haves.

  4. Low impact, high effort: Don’t bother, or not right now.

This approach also lends itself to visualization. Dedicated product management software or online collaboration tools like Mural or Trello are helpful for creating 2x2 grids, or you can go old school and draw a physical grid on a whiteboard or poster. Write each user story on a sticky note (real or virtual), then place it in the quadrant where you feel it belongs. Keep user stories in rough order of priority within the quadrant itself so you can work out what to address first. 

There should be a roughly equal number of tasks in each section. If you have too many user stories for your resources, move the effort line up until you have an appropriate number of user stories in the top-left quadrant.

At the end of this prioritization process, you should have a manageable list of tasks to undertake. Refresh the list of tasks once items are completed or new ones are added to ensure you’re tracking what’s done, what’s not, and what needs further analysis. It’s also worth doing a regular review, perhaps monthly, to confirm that the assigned priority and effort levels are accurate. If anything has changed—for instance, you’ve recently discovered a new customer requirement—this is an opportunity to add that user story to the mix.

Doing the work

Once you have your list of prioritized tasks, consider performing a few basic rituals when building your product to stay organized and keep collaboration productive.

First, establish a sprint cadence. I like two-week sprints because they’re just long enough to tackle substantive work. Too much longer, and you risk scope creep or losing focus. On a small, fast-moving project, even one-week sprints might do the trick.

Second, set up a planning meeting at the start of each sprint to select the items you and your teammates plan to tackle. Be sure to draw on your prioritization exercises when assigning tasks. At the end of the meeting, you should all know what you’re going to work on in the coming sprint.

Lastly, schedule a demo and review session at the end of each sprint. Demos give everyone on the team a sense of how a new feature works, which is especially helpful for features that other people will work with, integrate, or iterate on. (You could even invite users to the session to show them your progress.) These sessions provide an opportunity to celebrate accomplishments and get positive reinforcement on the work you’ve done so far. They also allow you to discuss what went well and what didn’t in terms of estimation and efficiency. For example, you might talk about why you underestimated a particular task and how to improve your analysis in the next sprint, or identify a tool, library, framework, or process that’s impeding development velocity.

Of course, if it’s just you working on the product, these rituals might not make sense—although you should still be capturing user requirements, recording user stories, and practicing prioritization on a regular basis. But once you have two or more people working on a product, it’s worth establishing these rituals in order to form healthy communication, collaboration, and organization habits.

Product management and you

There’s a lot more to product management than what I’ve shared here—it’s a vast discipline that extends beyond software to building products of all flavors. But this overview should give you a firm foundation. Having a solid understanding of how product management functions not only improves how we work with product managers, but also allows us to manage development when PM resources aren’t available. 

If you’re interested in learning more, I recommend the books Crossing the Chasm by Geoffrey Moore, The Lean Startup by Eric Ries, The Design of Everyday Things by Don Norman, The Innovator’s Dilemma by Clayton Christensen, and Game Thinking by Amy Jo Kim. Each contains further strategies for gathering information from your customers and building successful products. 

Now, go forth and product manage.

About the author

James Turnbull is VP of engineering at Sotheby’s and the author of 10 technical books about open-source software. Previously he was VP of engineering at Timber and Glitch, CTO at Microsoft for Startups and Kickstarter, and CTO and founder at Empatico.


Buy the print edition

Visit the Increment Store to purchase print issues.


Continue Reading

Explore Topics

All Issues