# Read Marty Cagan's Inspired and stop running a feature factory for your customers

> Marty Cagan writes for product managers, but his thinking names the trap FDEs fall into most often: shipping every feature on the customer's list without knowing what problem has been solved.

Bản gốc: https://fdetimes.net/en/books-courses/inspired-marty-cagan-fde-feature-factory/

Picture your first week in a customer's office. They hand you a file with 14 rows, each one a feature. You finish all 14, on time. Three months later nobody remembers what the ninth dashboard was for, and the renewal is still unsigned.

This kind of failure has a name. John Cutler, who has worked at Amplitude and popularised the term "feature factory", argues that the problem is not shipping a lot of features. In his view, a team goes off course when nobody takes the trouble to find out what the things it shipped have done in the medium and long term.

FDEs fall into this trap more easily than ordinary product engineers, because the customer is right in front of them and always has a list ready. That is why an author who writes for product managers deserves a place on your desk.

## What is the book about, and which parts are not for you?

The full title is *INSPIRED: How to Create Tech Products Customers Love*, second edition, by Marty Cagan. Wiley published the e-book in November 2017 and the hardcover in December 2017. Cagan runs SVPG, and the book's page on the company website describes it as a structured class in how to organise and staff a product team.

That detail tells you how to read it. Organisational structure and hiring for product teams are things an FDE rarely gets to decide, so you can skim them. What is worth keeping is how Cagan thinks about problems and results, and he sets out those ideas most concisely on the SVPG blog.

So a suggestion on order: read the two short posts "Product vs Feature Teams" and "The Four Big Risks" first, then open the book.

## Output is not a result

The idea most worth carrying away from Cagan's thinking is the line between output and outcome. In "Product vs Feature Teams", he defines the purpose of a product team as solving problems in ways customers love while also working for the business.

Product teams, he writes, are directed and measured by outcomes, whereas feature teams revolve around output.

On a customer site, the most obvious example is a request such as "add an export-to-Excel button on the orders screen". That is output. If you keep asking, you may learn that dispatchers spend hours every day reconciling orders by hand.

The outcome, then, is less time spent on reconciliation, and the export button is only one of many ways to get there, and not necessarily the best.

On site, the first thing to do is attach every feature to a number. If neither you nor the customer can say which number a feature will change, that is a sign you are running an assembly line.

**Điểm mấu chốt:** A customer's feature list is a hypothesis, not a purchase order.

## A roadmap as a list turns engineers into order-takers

That line leads to a different view of roadmaps. In "The Alternative to Roadmaps", Cagan borrows a general's warning and writes that the typical roadmap does exactly what the general advised against: it tells the team what to do.

In his post on feature teams, he observes that teams handed a prioritised list of work like this are usually not empowered at all.

FDEs can easily reproduce this structure for a customer without meaning to. You take the backlog, split it into tasks, report progress by rows completed, and the customer judges you by that same number. Cagan proposes a different approach to roadmaps, and his phrasing is compact: it is all about outcomes, not output.

You can apply this at your next planning session. Instead of sending the customer a plan of 14 features, send three problems to solve, each with a metric and a few possible solutions to try. You still ship code, but the conversation has moved on to results.

## Four risks: a filter before the first line of code

The most practical tool for engineers is the four-risk framework Cagan describes in "The Four Big Risks", and FDEs meet three of those risks every day. Value risk is whether customers will buy it or users will choose to use it.

Viability risk is whether the solution works for the business, across all its dimensions. Feasibility risk is whether engineers can build it within the time, skills and technology available.

Back to the export button. On value: do dispatchers really open the Excel file, or do they need a reconciliation screen inside the system? On viability: does the customer's data policy allow order information to leave the system as a standalone file? On feasibility: with the current stack and two weeks left, which version can you build?

In the same post, Cagan assigns value and viability to the PM and feasibility to engineers. On a customer site, FDEs usually carry all three roles, so make these three questions a mandatory checklist before accepting any request larger than a few days of work.

Practise on a second request: the customer wants the system to send an alert email whenever an order is late. Before taking it on, write down one answer for each risk.

On value: will recipients read the emails, or filter them out when dozens of orders are late every day? On viability: who on the customer's side is responsible for handling the alerts, and does their process have room for that step? On feasibility: is the delivery-time data in the system reliable enough to determine which orders are late?

Any question you can only answer with "don't know yet" is exactly the discovery work to do before writing the first line of code.

## Turning this thinking into an edge when job hunting

Claiming product thinking is easy; proving it is hard, and Cagan's language of outcomes gives you a way to do it. On your CV, instead of "built 12 features for a logistics customer", write the problem you solved and the number that changed.

When reading job descriptions, look for phrases such as "customer discovery", "own outcomes" or "work with customers to define the problem". Those are teams that expect you to ask questions, not just take tickets. For interviews, have a story ready about a time you turned down or redirected a customer request after checking the three risks above.

Inspired was written for people building product teams, not for FDEs. But the question running through Cagan's thinking, whether you are shipping features or solving problems, is exactly what separates an FDE the customer keeps from a contractor the customer replaces.

**Thử ngay tuần này:**

- Take your three most recent feature requests from customers and rewrite each as an outcome statement, with the number you will use to measure it.
- Read the two short SVPG posts "Product vs Feature Teams" and "The Four Big Risks" before opening the book.
- In this week's customer meeting, ask one more question before taking on work: "If this feature works well, which of your numbers will change?"

## Nguồn

- [INSPIRED: How to Create Tech Products Customers Love (2nd Edition)](https://www.svpg.com/books/inspired-how-to-create-tech-products-customers-love-2nd-edition/)

- [Inspired: How to Create Tech Products Customers Love, 2nd Edition](https://www.wiley.com/en-us/INSPIRED%3A+How+to+Create+Tech+Products+Customers+Love%2C+2nd+Edition-p-9781119387503)

- [Product vs Feature Teams](https://www.svpg.com/product-vs-feature-teams/)

- [The Alternative to Roadmaps](https://www.svpg.com/the-alternative-to-roadmaps/)

- [The Four Big Risks](https://svpg.com/four-big-risks/)

- [12 signs you're working in a feature factory — 3 years later](https://www.amplitude.com/blog/12-signs-youre-working-in-a-feature-factory-3-years-later)