The Quarter on One Page: A Date for Every Product Decision

The new quarter starts on Monday, and your leadership team is planning it. Your founder asks how this quarter's big bet did. Somewhere there's a page where you wrote down the number that would mean the bet worked, and the date you'd check it. The date was last week. Nobody looked, and that includes you. Meanwhile the no you defended back in January is on the table again, because on Thursday somebody caught the founder in a hallway.

Every date like that lives on the page where somebody wrote it, and a page doesn't remind anybody of anything. Every decision you own can have a date when it gets looked at again, and all of those dates fit on one page with the quarter across the top.

What Meridian wrote down

Meridian, the fictional company this series follows, sells shift scheduling software to logistics operators, and it has 40 people and 60 customers. Over the past few months it has written its decisions down. The strategy fits on one page. Its focus is logistics operators running 20 to 200 vehicles. It also has a decline, a sentence naming what Meridian won't do: no custom integrations for enterprise warehouse systems. In part six, Meridian wrote down the one thing that would change that decline: three customers in the focus needing the same thing. Nothing on the strategy page says when anybody will look at the decline again.

The head of product's other pages are scoreboards. Before anything ships, somebody writes down the number that would mean it worked (the bar) and the date to check it. This quarter Meridian has been building templates for the common overtime rules, and the product manager, who reports to the head of product, owns their scoreboard. His bar says five of the next six new customers will publish their first schedule inside a day, without calling support. His date to check it is the end of the quarter.

Two more dates are written down. The head of product coaches the product manager in a one-on-one every week, and she calls each board member the week before every board meeting. Only the board meeting itself is on a calendar the whole team shares. The scoreboard's date lives on a page, and the strategy has no date at all, so both get looked at when somebody happens to remember them.

Who does the remembering

In a very small company, the founder keeps track for everybody, because he can still talk to everybody. David Sacks, the venture investor, wrote that below about fifty people, founders "can easily run around telling everyone what to build and what to do." Verne Harnish, who writes about growing companies, sees that change coming a little sooner, at 40 employees, once a company starts adding managers. From there, he wrote, "it feels like you're reliving the same frustrating day, day in and day out."

Meridian has 40 people and a manager who reports to a manager, and its version of that day is the one when a decision it already made comes back. The people reopening a decline want something reasonable. A decline should be able to change, and Meridian wrote down what would change it. But a decision with no date for its next look comes back whenever something breaks, and the person it hurt is the one who brings it up. The head of sales loses a deal and raises it at the Monday meeting, or somebody catches the founder in a hallway. Either way the decision returns at the worst moment to decide anything, with the person who got hurt in the room and the evidence usually somewhere else.

Meeting rhythms

Harnish's answer to the frustrating day he described is a meeting rhythm, running from a daily huddle of a few minutes through weekly, monthly and quarterly meetings up to an annual planning day. Gino Wickman's version, the Entrepreneurial Operating System or EOS, has a ninety-minute leadership meeting every week and a full day every quarter to pick the priorities for the next ninety days. Harnish's firm and EOS both sell coaching, and both write for the CEO and the leadership team. Nothing I read in either gives a product decision a line of its own.

What both rhythms do well is hold off new work. EOS calls each quarter's priorities Rocks, and once the quarter starts, nobody adds a new one; new ideas wait on a list for the next quarter. Dan Martell, who coaches software founders, has his own way of saying not now. When somebody on his team pitches a big idea in the middle of a quarter, he calls it a great discussion for the annual planning day and has them add it to the planning document. The person has been heard and the idea has a date, Martell says, so they stop raising it in other meetings and don't try to start it on the side.

Sacks comes closest to product. The overall product roadmap, he writes, "should get reprioritized and resourced quarterly." That gives the roadmap a date. A decline isn't on the roadmap, so it needs a date of its own, the day it gets looked at again, and until that day the head of product can hold it.

The quarter on one page

A date of its own needs somewhere to live, so I drew one page with the 13 weeks of the quarter across the top. Throughout this series the product job has been four decisions: which problems you solve and for whom, what evidence justifies solving them, what you decline, and what outcome you expect. Each one changes at its own speed, so each gets looked at again on its own schedule.

The evidence can change any week, as customers tell you new things, so it gets a weekly row. Teresa Torres teaches product discovery, which means finding out whether an idea deserves to be built before you build it, and she defines the practice by weekly contact with customers. At Meridian, support and the account managers end their calls with a question the company wrote for this: the last time you needed your schedule inside another system, what did you do? Meridian had asked it once before, for two weeks, and then stopped. Two customers out of 60 had the problem, and nobody had asked since.

The weekly row holds two meetings as well. One is the product manager's one-on-one, which Marty Cagan, whose firm sells product training, says should never get canceled, because it's where the product manager learns to make the evidence calls himself. The other is the Monday meeting, which gets one standing item from product: what did we say no to this week, why, and when will we look at it again?

The outcome you expect gets looked at on its scoreboard's date, which for the overtime templates is the end of the quarter. The problems Meridian takes on, and the things it declines, get looked at once a quarter, at a strategy refresh. Quarterly is my choice. Cagan writes that a product strategy changes "at least yearly if not quarterly, based on new data and insights." That range is his judgment, and as far as I can find, nobody has measured it.

Every date on the page goes on the shared calendar, and the Monday meeting opens by reading the coming week's dates. Meridian already held a quarterly review of its scoreboards, so the refresh is the one meeting the page adds.

The quarter on one page The 13 weeks of the quarter run across the top, and every date also goes on the shared calendar. 1. Which problems you solve, and for whom: once a quarter, at the strategy refresh. 2. What evidence justifies solving them: every week, from a standing question on customer calls. 3. What you decline: at the same refresh, with what would change it written beside it. Evidence that meets that condition can move the refresh up. 4. What outcome you expect: on its scoreboard's date, read against the bar. Also on the page: the product manager's weekly one-on-one; the Monday meeting's standing item, "What did we say no to this week, why, and when will we look at it again?"; a call to each board member the week before every board meeting; and the quarterly review, which reads every scoreboard before anybody plans the next quarter.

Week 5: the founder's email

In week 5, the founder forwards an email from a prospect that wants a custom integration with its warehouse system, with one line on top: "Can we do this one?" The head of product writes back that the decline gets looked at again at the refresh, which is on everyone's calendar for week 13. The founder asks whether this prospect could count as the third of the three customers the decline's condition asks for. It can't. It runs 300 vehicles and has its own IT department, which puts it outside the focus. So the email waits, and the founder can see the date it will be answered.

Week 8: the third operator

In week 8, support's question turns up a third operator inside the focus, one with 80 vehicles whose dispatcher retypes the week's schedule into its warehouse system every Monday morning. That makes three operators in the focus who need their schedules in another system, which is the condition Meridian wrote down in part six.

Roger Martin, who wrote Playing to Win with A.G. Lafley, builds strategy around conditions like that one. For each strategic choice, you write down what would have to be true for it to be a good one, and you keep checking those things. He also argues against making a strategy wait for a fixed planning cycle. When something it rests on stops being true, he writes, "that is precisely the time to get to work." So the head of product moves the strategy refresh up from week 13 to week 9.

The question that separated the email from the operator is whether something touches the condition you wrote down. A lost deal from a customer outside the market you chose tells you somebody wants the decision changed, and that's pressure. Another customer inside that market, with the same workaround, meets the condition, and that's evidence.

The refresh in week 9

At the refresh, the head of product brings the count, now three operators, to the leadership team. The decline gets narrower. Custom integrations for enterprise warehouse systems stay declined, and a standard export goes on the roadmap, one way of getting a schedule out that every operator in the focus can use. It's a bet, so the product manager sets a bar for it and a date to check. The head of sales walks out with a new answer for operators in the focus, and the old answer for anyone who wants a custom project, including the prospect from week 5. Each board member hears about the change on the head of product's call, the week before the board meeting.

A no with a date on it can wait out a bad week.

The review comes before the plan

At the end of the quarter, Meridian reads its scoreboards before anybody plans the next quarter. Google's guide to setting goals with OKRs says the company meets every quarter to score that quarter's goals, and then sets new ones. A former executive at a startup called Swimply told a webinar audience that her company set yearly and quarterly goals but wasn't going back to check how one quarter went before writing the next. It got disciplined about looking back after a colleague arrived from Airbnb.

In part eight, Meridian's head of product took her scoreboard to the quarterly review and showed the bar before the result. This time the review is on the calendar. The product manager presents the overtime templates. His bar is five of the next six new customers publishing a first schedule inside a day, without calling support. Five did. The sixth got stuck importing its list of drivers, a step nobody had looked at, and that step goes into next quarter's planning.

One date

Find the decline you've defended the most times. Write down what would change it, and put the date it gets looked at again on the calendar everyone else uses.

Dave Saunders is the founder of Base Reality Group and a Fractional CPO for product companies. He was a founder and operator at Galen Robotics, where the surgical-robotics platform earned FDA De Novo authorization in 2023, and he managed a 35-patent portfolio licensed from Johns Hopkins. He wrote Founders Who Finish and publishes The Build. More about Dave →