Project Management for Product Development

The plan breaks between teams, not inside them

Ask an engineering lead if their team is on track and you'll usually get a real answer, because the sprint board tells them. Ask whether the product launches on schedule and the honest answer often depends on things that sprint board can't see: whether design finished exploration in time to hand off a spec, whether marketing has the assets they need with enough runway before launch, whether sales was briefed before or after the announcement went out.

Product development is the level above any one team's execution. Each function (design, engineering, marketing, sometimes sales and support) runs its own process at its own pace, and the plan only holds together if the handoffs between them happen on time. A team can hit every sprint goal it set and still watch the launch slip, because the thing that slipped was never on that team's board to begin with.

The usual fix is a master spreadsheet someone maintains by asking four team leads for updates every Friday. It's stale by Monday and nobody trusts it enough to actually plan around, which is exactly the problem it was built to solve.

There's a second cost to that spreadsheet approach that's easy to miss: it makes the handoff points themselves invisible. A spreadsheet shows four teams' rough status; it rarely shows that engineering's sprint literally cannot start until design's spec is signed off, which means a two-day slip in design becomes a two-day slip in engineering's start date, quietly, with no line item that says so.

By the time that compounding shows up as a missed launch date, it's usually too late to do anything but apologise for it. Catching a two-day slip in design while it's still two days, rather than after it's propagated through three more handoffs and become a two-week miss, is really the entire argument for tracking cross-functional work as one connected plan instead of four separate ones.

One roadmap, several vocabularies underneath it

The fix isn't forcing marketing to use sprint points or making design estimate in story points that don't mean anything to them. It's giving each function its own board, in its own vocabulary, rolled up into one place someone can actually look at without translating four different systems in their head.

Design tracks concepts and review rounds. Engineering runs sprints against a spec once it's handed off. Marketing tracks launch assets and campaign timing against the same release date engineering is building toward. Each team works the way that team actually works, and the dependency between "design finishes the spec" and "engineering starts the sprint" is a visible link on the roadmap, not a hope. That link is the actual product here: not a bigger backlog, but a plan where a slip in one function is visible to the next one before it becomes their surprise.

The wiki is where the parts that don't fit on any single board live: the brief that started the project, the decision to cut a feature at the midpoint, the positioning that changed after a competitor moved. Any line on that page can become a task, so a decision made in a meeting doesn't quietly fail to reach the team that needed to act on it.

The handoffs that actually determine the launch date

Most product launches don't slip because any one function was slow. They slip at three specific, recurring seams: design-to-engineering, engineering-to-marketing, and marketing-to-sales. Each is a moment where one function's output becomes another's input, and each is a place where "roughly ready" quietly gets treated as "ready."

Design-to-engineering is the most common failure point, because a spec that looks complete in a design file often isn't complete enough to build from (missing states, missing edge cases), and that gap doesn't surface until an engineer is already mid-sprint. Engineering-to-marketing fails differently: marketing needs lead time to build a launch campaign, and if the forecasted date keeps moving without marketing knowing, the campaign gets built against a date that's already wrong.

Naming these three handoffs explicitly, with a task and an owner at each seam rather than treating them as automatic, is a small process change that catches most of what actually causes launches to slip, long before the slip becomes visible in an all-hands update.

The marketing-to-sales handoff gets less attention than the other two but causes its own kind of damage: a sales team briefed late walks into customer conversations a step behind their own company's announcement, which is a bad look that's entirely avoidable with a task and a date rather than an assumption that "sales will hear about it eventually."

What a clean handoff between functions actually looks like

• A concept doesn't move to build until design sign-off is logged, not assumed from a meeting nobody wrote down
• Engineering's sprint plan reflects the actual spec handed off, not the one from three revisions ago that's still floating in someone's inbox
• Marketing's asset and campaign timeline is tracked against the same forecasted launch date engineering is working toward, not a fixed date set eight weeks earlier
• A scope cut made mid-project is written down once, in one place, and every affected board sees it

None of these are engineering practices borrowed for product work. They're the specific points where cross-functional plans usually come apart, made visible enough to catch before they do.

Where this connects to a single team's execution

Once a spec is handed off, engineering's side of the work runs the way any engineering team's does (sprints, GitHub-synced cards, cycle time), covered in detail in the software development use case. Product development sits one level above that: the view that ties engineering's sprint to design's review round and marketing's launch date.

Every function, including HR and operations, if the launch needs new hires or new process, runs on the same subscription with its own templates; see how the platform is put together for the full picture beyond this one use case.