From Request to Deliverable: The Marg Manual
The product team
When to call this team
Product is the team for the gap between three things that rarely agree: what users say, what users do, and what you build next. Reach for it when:
- Feedback is arriving from six channels and no one has synthesized it in months.
- The next sprint has twelve candidate features and capacity for four.
- You are about to A/B test something and want the test to actually settle the question.
- Activation looks fine in the dashboard while churn quietly says otherwise.
- You need to see what is rising in your market before it becomes obvious to everyone.
Every one of these is a decision about where to point limited build capacity, which is the most expensive thing a startup spends. The team exists to point it well.
Who shows up
The product orchestrator runs a focused bench and assembles it around the decision in front of you:
- Product manager, who owns lifecycle thinking from discovery through go-to-market.
- Feedback synthesizer, who turns raw user input into quantified priorities.
- Experiment designer, who builds A/B tests rigorous enough to trust.
- Sprint prioritizer, who forces honest impact ranking against capacity.
- Behavioral nudge engine, for engagement and activation mechanics.
- Trend and internet researchers, who feed the team signal from outside the building.
Three worked examples
"What is our feedback actually telling us?" The feedback synthesizer takes what you share, support threads, reviews, interview notes, and returns themes ranked by how often they appear and how much revenue sits behind them, which separates the loud complaints from the common ones. With product analytics connected, it checks what users say against what they do, and the gap between the two is usually where the real insight is.
"Plan the sprint." The sprint prioritizer scores the candidate list against impact, effort, and the strategy already in your profile, then hands back a ranked sprint with explicit cut lines and the reasoning behind each call. You are meant to argue with it. The reasoning is shown for exactly that purpose, so the ranking is a starting position rather than a verdict.
"Design this test properly." The experiment designer turns "let's test the new onboarding" into an actual experiment: a hypothesis, the sample size, the minimum detectable effect, the duration, and the rule that decides ship or revert before you start. Most underpowered tests die right here, on paper, which is far cheaper than dying after two inconclusive weeks of live traffic.
What they need from you
The raw material, unpolished: the actual feedback text, the candidate list with rough effort guesses, and what you believe so the team can test it. Connecting PostHog moves behavioral analysis from MEDIUM to HIGH evidence, and connecting Linear lets sprint work read your real ticket state instead of a described one.
Hand-offs
Product decides what to build, then passes the doing to its neighbors. Validated priorities go to project management for delivery (chapter 14). Experiment results that touch pricing or strategy go to advisory (chapter 9). And the user problems behind upcoming work go to design (chapter 13), so the people drawing the screens start from the same evidence.