DigitableCourses
Portal settings
Show me around

Local and account-free. No account, no sign-up: whatever you type into the tools stays in this browser's localStorage and never reaches a server.

Our own counter records page opens and finishes: the address leaves, plus one tenth-of-the-text figure. No cookies, no outside trackers, your IP is not stored, Do Not Track is honoured. How to check that

The portal's own repository is not published, so we do not call it open source. What is open:

The portal lives on donations, paid consultations and requested write-ups, and on Workbench sales.

There are no plans to make the courses paid.

Career

Product manager

Decides what to build and why, and answers for the outcome rather than for the volume shipped.

  1. Entry
  2. Core level
  3. Senior and beyond

Compared with engineering work, the measure of success changes: not what has been shipped but what people started doing differently.

Do now

  • I talk to a user without feeding them the answersWhat I take out of the conversation is the problem, not a confirmation of my idea.
  • I choose a metric that cannot be gamed without making the product betterI can name where it could be cheated and why that will not work here.
  • I explain to the team the reason an idea was turned downA no has an argument behind it rather than a line about what was decided.
  • I write the statement of work with the behaviour on errors and on empty statesThe team does not come back asking what happens if the service is unavailable.

Where next

Core level

Sideways out of the role

What this step asks of you

  • I talk to users without feeding them the answersWhat I take out of an interview is a description of the problem, not a confirmation of my idea.
  • I choose a metric that cannot be gamed without making the product betterI can explain how my metric is connected to money and where it can be cheated.
  • I prioritise in a way that lets me explain the decision to the teamA refusal has a reason behind it, not a line about what was decided upstairs.
  • I state a problem so that it can be builtThe team does not come back asking what to do if the service is unavailable.

Common mistakes

  • Collecting wishes and calling it prioritisation: the list grows and no direction appears.
  • Asking users what to build: they name a solution, not a problem.
  • Measuring success by the volume shipped: the team is busy and the product stands still.

What to learn

  1. Entry
  2. Core level
  3. Senior and beyond

What you are held to account for changes: not the tasks put into the plan but whether the direction chosen turned out to be the right one.

Do now

  • I write a hypothesis down together with the result that would refute itThe experiment is allowed to end in a no, and that is agreed in advance.
  • I say no to a good idea and explain what it gets in the way ofThe plan has a logic to it rather than a list of wishes from stakeholders.
  • I count the unit economics of my product myselfI know what acquisition costs and what a user brings in.
  • I come to the team with a problem rather than with a ready solutionThe team proposes a cheaper way and understands what it is for.

Where next

Senior and beyond

Sideways out of the role

What this step asks of you

  • I test hypotheses with an experiment, not with a meetingThe hypothesis says in advance which result would refute it.
  • I hold a strategy and can say no to a good ideaThe roadmap has a logic to it, not only a list of wishes from stakeholders.
  • I count the unit economics of my productI know what acquisition costs and what a user brings in, not only the DAU.
  • I work with the development team without turning into a dispatcher of tasksThe team knows why it is building a feature and can propose a cheaper solution to the same problem.

Common mistakes

  • Becoming a dispatcher of tasks: the team stops understanding why it is building what it is building.
  • Stopping an experiment on a convenient number: the decision gets made on noise.
  • Piling up promises to stakeholders: the plan turns into a queue where everything is urgent.

What to learn

  1. Entry
  2. Core level
  3. Senior and beyond

Senior and beyond

Straight to the self-check

The unit of work changes: instead of one direction there are several bets at once, and closing some of them will fall to you.

Do now

  • I shut down a direction that did not work out and tell people what it taught usI have bets that are closed, not only bets that are launched.
  • I check somebody else's report for a survivor sample and for a swapped causeI tell data apart from the interpretation of it and say so out loud.
  • I take an agreement with stakeholders through to a decision that is written downWe do not come back to a settled question at every meeting.
  • I discuss technical debt as a product decision rather than as a whim of developmentThe debt has a place in the plan and a price that has been named.

Where next

Not another step — a fork

Sideways out of the role

What this step asks of you

  • I manage bets, not tasksI have directions I shut down, and I can explain what they taught us.
  • I tell data apart from the interpretation of itI do not confuse correlation with cause, and I spot a survivor sample in somebody else's report.
  • I negotiate with stakeholders whose goals are opposedThe agreement holds for longer than one meeting.
  • I understand the technical price of my decisionsI can discuss technical debt as a product decision, not as a whim of the developers.

Common mistakes

  • Demanding that every bet pay off: the team starts hiding its failures.
  • Believing a single source of data: a number nobody has double-checked starts living a life of its own.
  • Winning the argument instead of reaching agreement: the agreement holds until the next meeting.

What to learn