Praxis Product Management

The Craft Vs. The Job of Product Management

It strikes me as silly to begin a blog about product management with a section covering “What is product management?”—and yet here we are—falling into the common trap of nonfiction—which spends the first few chapters selling you the book you’re already reading.

I emphasize what product management is—because many product managers don’t quite understand what product management is.

As a thought exercise—what is the minimum team size needed to ship a software product to customers? Or worded differently, what is the leanest (successful) software product you can think of; how many people were involved in building it?

When I ask this question at workshops, the most common answer is three: a product manager, an engineer, and a designer.

The answer is one.

There are several successful products with an original team size of one, including Facebook, which was defined, designed, and coded by Mark Zuckerberg. On the smaller side, Balsamiq mockups were notable for its solopreneur path to $6M in revenue.¹

Building up from first principles, the minimal needed for a successful product is a functional idea. Anyone can have an idea—it’s not the exclusive domain of product managers nor a company’s employees—so the limitation is functional. You need the product built.

So now you have one person, who has made an idea functional, but let’s say this person isn’t very good at thinking through the flows and making the product compelling. This hypothetical person finds a designer to join them on the team.

The team is in luck turns out this functional idea is also highly desirable by the market, it’s built, and thanks to the expanded team, it’s now well-designed.

So where does product management come in? In this case, it doesn’t have to. But as the team expands, it becomes less likely that new team members have the same superpowers to handle the combination of responsibilities of defining, designing, and building the product well.

It becomes harder and harder to replicate this initial success; this is where the product management discipline is typically introduced. After the initial founding and a few in-market stumbles, product management is added not to manage the team, the specs, or the process—product management is added to manage the product.

Product management is added to manage the product not the team or the process, but the product.

The statement is as simple as it is complex.

The reason why product management varies so wildly from one team to the next is because it should. We’re not a project management discipline but we’re expected to have project management competency, we’re not a technical discipline though we’re expected to have technical acumen with our fields. We’re not a design discipline though we’re expected to define the intended design outcomes.

Each product and organization, depending on its phase, team skill, and composition, will need more or less of each skill and so much more because product management is not a job. It’s a craft.

Whereas a software engineer’s work might is complete when the product works, or design when the work is design complete—the product manager is constantly evaluating and scanning the internal and external environment for opportunities to increase the odds of marketplace success for the feature, the value proposition, and for the product as a whole.

A given job description might focus on the meetings, and the artifacts product managers typically produce. The craft of product management refers to the journey of acquiring new skills and knowledge—each to increase the probability of your product’s marketplace success.

As defined by the craft, a product manager must continuously pursue information and skills that may be of future use to the product.²

Therefore, a core responsibility of a product manager is to define what information (and skills) are most needed to increase the probability of marketplace success.

This work defines typically falls into three groups:

1. What are we building
2. How will we know if we’re on the right track
3. What might inhibit or enhance our success
   

Overtime the discipline has organized these information needs into a set of distinct product activities (Definition, Design, Development, and Management, which we’ll cover in the following chapter)—but if you’re on top of these three types of information and successfully aligning your product team and leadership on those three pieces, you’re nailing the craft of product management—if it’s on a whiteboard, a napkin, or a google doc.

1. The SaaS Podcast: How Balsamiq Bootstrapped Its Way Into a $6M Business – with Peldi Guilizzoni https://saasclub.io/podcast/peldi-guilizzoni-balsamiq/ ↩
2. Note information does not exclusively refer to data—I’ll cover later why data is the lowest form of communication. ↩

---