Linear · Product sense · Mid · 45 to 60 minutes

How should Linear handle project status sharing?

Linear is a software product for planning and building products, best known for issue tracking, projects, and roadmaps used by product and engineering teams. Answer this product management case and get it graded line by line against a weighted rubric.

problem framing
prioritization
product sense
MVP design
metrics

The situation

A product lead at Linear asks you to evaluate a problem that has surfaced while the team is working on improvements around Projects and roadmap workflows. In customer conversations and internal use, teams can plan work and track progress in Linear, but many still step outside the product when they need to explain where a project stands, what changed, and what others should know. They use ad hoc docs, chat messages, or meetings to keep stakeholders aligned. This is not part of the original plan for the current roadmap, so the team is split. One view is that this is a real gap in the Projects experience and a chance to make Linear more useful as the system of record for product development. The other view is that status communication is broad, easy to overbuild, and could pull the product away from its focus and simplicity. You need to recommend whether Linear should invest in this problem now, what the smallest sensible approach would be if yes, and how to validate the choice before it turns into a large feature area. Assume you have access to recent qualitative feedback and basic usage patterns from the Projects area.

What to produce

A 1 to 2 page product recommendation memo.

Your answer must

State the core user problem in one clear problem statement and explain why it matters now.
Identify the primary users and at least one secondary audience, and describe their jobs to be done.
Make a recommendation on whether Linear should invest now, defer, or decline, with reasoning tied to product strategy.
If you recommend investment, define the smallest useful first version and name what you would explicitly leave out.
Describe the main trade-offs and risks, including the risk of adding complexity to Linear.
List the success signals you would track in the first release or validation phase.

Constraints

Your proposal must fit naturally within Linear's existing Projects experience and product philosophy of speed and simplicity.
Do not assume a standalone new product area, a major org change, or a long multi-quarter build.
You have limited evidence because the problem surfaced during adjacent work, so your plan should not depend on heavy upfront research.

Format

Use brief sections with headings such as problem, users, recommendation, first version, risks, and success measures.

How Linear actually played it

Linear tells how Project Updates emerged as a problem space while building other roadmap items, rather than from the initial plan. The post covers the discovery path and the design decisions. A look at how features appear during planned work.

Good ideas can emerge while building adjacent work
Ground features in a clear problem space
Ship a small version and refine from use

Built from How we built Project Updates by Andreas Eldh.