What better place to start talking about product management than around the bedrock book, Inspired by Marty Cagan? Hat tip to Pete Anderson for recommending. As a recap, Cagan and his team are Silicon Valley Product Group, together they're often considered the go-to folks and namers of the collection of roles and values called "product management". Really their aim is to help folks work well at the intersection of design, technology, and business to create useful and valuable products. These goals might be considered under other titles, and they might be met in different ways. One of these ways is Basecamp's Shaping. I'll contrast in a future post.

For now, I'll take a tour through Cagan's book, sharing my notes and things that stuck out to me. This might be considered in the spirit of various book summary sites or aggregators (e.g. Actionable Books).

We'll do it in four parts, corresponding roughly to each of the main sections of Inspired. At the end I'll try to leave with some questions or a prompt, in the spirit of Software Developer Mickey Muldoon's suggestions for learning that compounds.

Part One of Inspired is:

Lessons From Top Tech Companies

1. Behind Every Great Product

Product management is an intersection of fields, the bottom line is that it's about what to build.

2. Techonology Powered Products and Services

The book's focus is tech-powered products from companies like Apple, Workiva, Airbnb, and Twitter. Though the lessons may transfer to other domains as well.

3. Startups: Getting to Product/Market Fit

In startups, the product manager is usually a cofounder. There are < 25 engineers, and it's a race against running out of money to find product/market fit. Product/Market fit was a concept espoused by Mark Andreesen.

4. Growth-Stage Companies: Scaling to Success

Companies Grow, and you'll start to hear about "tech debt". Where tech debt is the stuff that needs fixing that went ignored in early days of the company.

5. Enterprise Companies: Consistent Product Innovation

In larger companies, "innovation centers" might show up to try to get innovation happening. The latter bodes poorly because it already suggests that innovation should be quarantined to a discrete unit of the company.

6. The Root Causes of Failed Product Efforts

An "Agile" working methodology or culture, as it shows up in organizations, is often just a disguised form of waterfall. One way a product can fail is by making a business case too thoroughly and too early -- we can't know what the product is going to cost yet, or even quite what it will make. If we do UX and design in waterfall, it's like putting lipstick on a pig -- just dressing up the wrong product. Product management, in these cases, ends up being merely a machine that turns a project into user stories and functional requirements. There might be QA, and then finally an engineering team starts implementing, maybe at this point introducing an interative workflow (often a signifier of agile practices).

Engineers, in this way of working, are brought in way too late. They're disempowered, and the org has missed out on using their innovation. Even moreso, the customer is brought in way too late.

This way of working is project-centric and outputs-focused. Whereas product management is outcome-focused. Product management in this model is actually project managment, simply turning projects into requirements and documenting them.

7. Beyond Lean and Agile

Spending months on a Minimum Viable Product is not agile. Three principles that are good indicators that we're actually doing things in an agile way:

1. Risks are tackled up front. This includes risks like value risk (whether customers will buy).
2. Products are designed by parts of the team collaboratively, rather than sequentially. IE marketing or customer experience teams don't simply come up with requirements that get passed on to designers.
3. We're solving problems, not implementing features.

8. Key Concepts

We aim for a holistic product. That includes functionality, technology, UX design, how we monetize, how we acquire customers, and even offline experiences.

A few questions to leave you with:

Take a few minutes to give these a thought, maybe jot a few notes or make a sketch that addresses each:

1. What ways have you seen agile principles at work around you? When did you suspect they were not truly agile and why?
2. What's an example of a communication you might have with someone from marketing (or customer experience), design, and engineering, given feedback from a user survey or focus group that the first mvp is not quite what the customer is looking for? Can you do this kind of communication without specifics? Would you meet with the representative of each function simultaneously or asynchronously (relaying information between them)?
3. What does product-market fit mean in the context of working on solutions for "internal customers"/partners?
4. How might the key concepts translate to non-software products? Feel free to consider something like 'hard tech' (emerging biotech, hardware like pebble, or something more at the intersection of software and hardware, like transcriptic, or SmartThings.