The document discusses how to build a customer-driven product team. It recommends structuring teams with 3 people (engineer, tech lead, engineer) to allow for autonomy and accountability. Each team is paired with a product manager, designer, and marketer to gather customer feedback and iterate quickly. The approach scales by having teams own products end-to-end and share metrics with internal stakeholders. Continuous delivery is key, with teams shipping updates daily to get quick feedback. This creates a feedback loop that puts customers first.
64. And each team shared public internal
metrics with each of their counterparts.
65. Example: Support. Each team was
measured on decreasing the call-drivers
on the list that their Support counterpart
had created each month.
66. Example: Sales. Each team was measured
on fixing the issues and adding the
features that their Sales counterpart had
prioritized based on win/loss data.
68. … including the freedom to not have things
like roadmaps and version numbers.
69. The way I think about it: those things (e.g.
roadmaps) are company problems, not
customer problems.
70. Customer needs will inevitably change
over time, which means your product will
need to change too.
71. There is no real end-goal. The end-goal is
evolution.
72. The only thing that I pushed for was that
teams shipped as soon as possible.
73.
74. I eventually got to the point where our
teams were shipping 500 to 600 times
every single day.
75. Instead of having two to three releases per
month, we had thousands.
76. We put products into the hands of beta
users immediately so they could help us
correct and iterate on our direction.
77. The proof of this new approach was in the
results, and those were results we saw
directly from customers as well as from
within the teams themselves …
78. After implementing the new structure, our
product team had the highest employee
NPS score of any team in the company.