Problem
In a small founder team under pressure, recurring coordination could either protect focus or turn into repeated debate.
Product management proof
I own the operating cadence around Pier: Linear updates, standups, midday check-ins, end-of-day reviews, planning, and written decisions from the responsible owner.
Problem
In a small founder team under pressure, recurring coordination could either protect focus or turn into repeated debate.
What I owned
I managed the ritual system so planning ended in visible ownership: Linear tickets, due dates, written briefs, shorter meetings, and unresolved decisions pushed to owners within 24 hours.
Result
The cadence made work easier to inspect, reduced time spent coordinating in meetings, and kept SmartApply launch work, value-map updates, and parallel validation plays tied to explicit owners.
Internal team rituals and planning records have been summarized for public use.
In a small team, product management often shows up as operating cadence. The question is whether the cadence actually changes the work.
I managed Linear and owned the daily rituals around Pier: standups, mid-days, end-of-days, planning sessions, and the habit of turning discussion into visible ownership.
At the beginning, we thought it might be better to avoid recurring rituals and let operators operate without extra friction. What we learned was almost the opposite: short touchpoints were what let the team stay aligned enough for the rest of the day to stay mostly free for work.
That was the tension: the ritual had to create clarity without becoming the work. If it only produced more meetings, it was failing.
The rituals became a way to maintain short-term alignment without losing sight of the company’s medium- and long-term objectives. That mattered most during high-pressure weeks, when external deadlines and founder stress could easily turn planning into repeated debate.
One practical improvement was ending short planning meetings with individual Linear tickets tied to each person’s contribution. For each ticket, we recorded an owner, next action, contribution, and follow-through.
That sounds ordinary until you have been in the opposite version: a meeting ends, everyone remembers the decision slightly differently, and the same issue comes back the next day.
Later, the planning process became sharper: written briefs before meetings, a 30-minute cap, and unresolved decisions pushed into written owner decisions within 24 hours.
Short check-ins helped us agree on priorities and responsibilities, then spend most of the day working rather than coordinating.
The team had a clearer cadence for product work under pressure. SmartApply launch learning, updates to the product value map, and parallel validation work could move through explicit owners instead of recurring debate.
I judge a check-in by whether the team leaves with a clearer decision, owner, risk, or next action.