Lore

product management

The Knowns and Unknowns of Building Products (featuring Jason Fried and Bob Moesta)

Jason Fried argues that most teams work backwards by assigning tasks upfront based on a false sense of what's known, when instead a project should be 'shaped' at a rough level and handed to a small team to discover the actual work themselves — and that progress should be measured by tracking knowns vs. unknowns (Basecamp's Hill Charts) rather than by linear percent-complete, because percentage figures hide which remaining work is still unknown and therefore risky.

Product Collective (A Mind the Product Community) · 2024-05-10 · English

Key ideas

  1. Most teams plan by lining up and assigning tasks to people upfront, which Jason Fried calls 'backwards,' 'a broken way to work,' even though it's how most teams operate.

  2. At 37signals, a project (not individual tasks) is handed to a team, and the team discovers the actual work itself as they go.

  3. Before handoff, the idea goes through 'shaping the work' — roughly explaining the concept and its general shape without finishing all the details.

  4. An idea at handoff is described as 'a malleable piece of clay' with only a general sense of shape; the team molds it into the final thing.

  5. Assigning fixed tasks upfront removes people's minds from the process; Fried wants '54 minds, 55 minds' at a 55-person company, not just executors.

  6. Teams are hired as problem solvers ('that's why we hired them... I don't hire people just to type code'), so they must discover the work by thinking through the approach themselves.

  7. 37signals maps projects with 'Hill Charts,' a feature built into Basecamp only, based on the idea that work is shaped like a hill (uphill, over the top, downhill) rather than linear.

  8. The first half of a project is full of unknowns ('uphill'); once the team gets over the hill on a problem, the rest is execution ('downhill').

  9. Percentage-complete metrics ('25% done,' '80% done,' '90% done') are described as meaningless without knowing what's known vs. unknown, since the last task left could be the hardest and least understood one.

  10. The correct way to measure a project, per Fried, is by what's known and unknown, not by completion, 'not undone and not done' — that's where confidence comes from.

  11. If a team is stuck at the top of the hill with big unknowns remaining and little time left, Fried says that's a dangerous position ('you're in deep deep [__]').

  12. Mike's breakdown reframes the team structure: at 37signals a product team is (per his understanding) a designer and a developer, with no dedicated product manager — the designer plays the PM role.

  13. Fried's stated reason for not assigning requirements upfront is that doing so limits creativity and risks building the wrong requirements — ones that aren't best for the product.

  14. Hill Charts — A feature built exclusively into Basecamp, based on the idea that project work is shaped like a hill (uphill through unknowns, over the top, then downhill through execution) rather than a linear percentage. Apply: Instead of reporting a project as X% complete, plot pieces of work as either still climbing the hill (unresolved unknowns) or past the top and heading downhill (known, just execution) to see where the real remaining risk is concentrated.

  15. Shaping the work — 37signals' practice of roughly explaining an idea's concept and general shape to a team before handoff, without finishing all the details or specifying tasks — described as turning a 'malleable piece of clay' into something explainable. Apply: Bring a team a rough concept and general shape of what you're trying to achieve rather than a finished requirements list, then let the team work out how to mold it into the final feature.

  16. Assigning projects, not tasks (small autonomous product team) — 37signals hands a whole project to a small team rather than pre-assigning individual tasks; Jason Fried says such a team is usually three people, while Mike's recap describes it as typically a designer and a developer with the designer also acting as product manager. Apply: Give a small team ownership of an entire project and let them discover and define the specific tasks themselves, rather than pre-assigning a task list, so the people executing are also the ones solving the problem.

Insights

The critique of percentage-complete isn't about sandbagging or inaccurate estimation — it's that percentage hides where the risk sits: being '90% done' by task count can still mean the single hardest, least-understood task is the 10% left, and it can take longer than the first 90%.

The team structure (no dedicated PM, designer doubles as PM) is presented as a direct consequence of the 'let the team discover the work' philosophy, not an independent org-design choice — separating requirements-writing from building would reintroduce the assign-and-execute pattern the approach is meant to avoid.

Fried frames team autonomy partly as a resourcing argument, not just a cultural one: paying for 55 people's problem-solving minds while only using 4 of them (with everyone else as executors of pre-set tasks) is framed as a waste of what you hired for.

Hill Charts encode an explicit asymmetry between the two halves of a project: the uphill (discovery/unknown) side is unpredictable in duration and risk, while the downhill (known/execution) side is treated as effectively 'coastable' — so the meaningful reporting question is which side of the hill the remaining work is on, not how many tasks are checked off.

«this is backwards and it doesn't work it is a broken way to work yet it's probably the way most teams work»

— 02:35

«shaping the work which is kind of roughly explaining like going through the idea and roughly getting to a point where we can explain the concept to a team»

— 02:58

«an idea is not a finished an idea is a is a malleable piece of clay»

— 03:24

«I want 54 Minds 55 Minds at our company with 55 people I don't want four minds»

— 04:09

«we think that work is shaped like a hill which means it starts here goes up comes down and flattens out»

— 04:39

«25% means nothing 80% means nothing these percentages don't mean anything because there's no context»

— 05:32

«you've got to figure out what's known and unknown and measure projects based on that not on completion not undone and not done but what's known and unknown that's where you gain confidence»

— 06:09

«if you're stuck at the top or if you're not stuck at the top yet you have two weeks to go and everything is unknown or the big points remain unknown you're in deep deep»

— 06:06

«at 37 signals you kind of have to play that dual Ro function that Designer is also acting as the PM»

— 07:08

Reception

The single comment is a neutral, matter-of-fact observation with no clear positive or negative sentiment.

This is a compact, faithful explainer built around a single 2019 fireside-chat clip, restating Jason Fried's two 37signals practices — shaping-then-discovering work and Hill Chart-based known/unknown progress tracking — without introducing claims beyond what Fried and the host say on screen.

12:06

↳ Product Collective (A Mind the Product Community) · YouTube

Watch original