Product
A small product team gets three concrete things from Business-Gym today: friction signals from your real website turned into observations a Head can reason about, goals whose numbers are measured rather than typed, and a project board where the resulting work lands. That is a useful loop, and it is deliberately smaller than “product analytics”.
This page is written for a Muster-GmbH-sized team — a handful of people, one product, no dedicated analyst. Where something is partial or missing, it says so.
What does a small product team get today?
Section titled “What does a small product team get today?”Four surfaces carry the product workflow, and each one is live enough to use on a normal week. They connect in one direction: a signal becomes a proposal, an approved proposal becomes a backlog item, and the work itself runs on the project board against a goal you can measure.
- Website friction — Clarity’s behavioural signals, read-only, on the Mesh impact page.
- Feature proposals and a feature backlog — the AI-PM clusters real signals into proposals you approve, defer or reject, and approved ones land in a durable backlog table.
- Goals (OKRs) — key results bound to live metric sources, with an honest “no signal yet” where nothing can measure them.
- Projects and tasks — a board with a kanban, milestones, risks and a status tab, linked to a Goal.
A Product Head and a Project Manager Head are created for every workspace during provisioning, so you do not have to set them up. Both draft and propose only — see working with a Head.
Where do the friction signals come from?
Section titled “Where do the friction signals come from?”They come from Microsoft Clarity, which you connect yourself under Integrations by pasting a Data-Export token. The connection is read-only: connecting Clarity never gives Business-Gym a way to change anything on your site.
Four friction metrics are read and shown as a percentage of sessions: rage clicks, dead clicks, quick-backs and JavaScript errors. They appear on the Mesh impact page as “Website friction (Microsoft Clarity)”, with a link out to Clarity itself for the session recordings.
The same four metrics feed the AI-PM as usage observations, which is how a real user problem becomes something the system can propose against. Each observation carries its source so a proposal can cite it.
If Clarity is not connected, or is connected but has no data, the panel renders nothing at all rather than showing zeroes. See integrations for how the connection behaves and what else is read-only.
How does a friction signal become something to build?
Section titled “How does a friction signal become something to build?”The Feature proposals page clusters real signals into a small set of proposals, and you decide what happens to each one. It is owner- and admin-only, and nothing on it is built by the system.
Each proposal shows the need, the evidence, who it helps, a rough scope, dependencies, a priority, and — the part worth checking — the signal sources it derives from. A proposal that cannot cite a real source is dropped before you ever see it, so an empty page means the signals did not support anything, not that the feature is broken.
You choose Approve, Defer or Reject. Approving records the decision and materialises the item into the Feature backlog, a table with a status you can move through planned · in progress · built · shipped and a Copy draft ticket button for pasting into whatever tracker you actually use.
How do I measure a product goal?
Section titled “How do I measure a product goal?”You bind each key result to a live metric source instead of typing a number into it, which is what makes a product OKR worth keeping open. Open Goals, expand a key result, and the binding panel lets you choose whether the source feeds the key result or its guard, pick a connector, enter a query, and set a refresh of hourly, daily or weekly.
The connector field offers the readers that actually exist and warns you when you type one that does not, because a misspelled connector is a binding that silently never syncs. Clarity’s metrics are bindable this way, so “quick-back rate below 8%” can be a real key result rather than a note.
Where nothing is bound, the key result reads “no signal yet” and the roll-up tells you how many of your key results have a real signal. Goals and OKRs covers the binding mechanics, guards and the manual-value escape hatch in full.
Where does the actual work live?
Section titled “Where does the actual work live?”Work lives on Projects, which is a per-tenant board rather than anything product-specific. Each project carries a status (planning · active · on hold · done), a health rating (on track · at risk · off track), a due date, and counts of its tasks, milestones, risks and pending approvals.
Opening a project gives you four tabs: Board (a kanban), Milestones, Risks and Status. A project can be linked to a Goal, and the list flags active projects that are not — with a suggested best-fit Goal — because an unlinked project cannot be prioritised or measured against your OKRs.
The Goals page also carries a shared task board: the human tasks in your workspace, grouped by status, each showing the key result it advances. It is read-only — it surfaces work, it does not reassign or close it.
Does the Product Head do anything on its own?
Section titled “Does the Product Head do anything on its own?”No. The Product Head drafts and proposes; it does not ship, send or change anything without you. Its charter tells it to be evidence-led, to escalate anything that needs a human decision, and to never invent metrics or commitments — which is why an unmeasurable key result stays visibly unmeasured.
Business-Gym as a whole runs at supervised autonomy today: proposals are produced, a person approves. External sends and anything touching money stay human-approved permanently — that is the hard floor, and no autonomy setting moves it. Approvals themselves are worked in one place; see working the approval queue.
What is not available yet?
Section titled “What is not available yet?”Several things a product team would reasonably expect are genuinely absent, and knowing which ones saves you planning around them. These are current gaps, not roadmap descriptions.
Operations analytics is not built. Automation rate, time saved and playbook performance are computed in code but have no screen, so you cannot see them today.
There is no product analytics view. PostHog’s server-side read is not provisioned, so the only usage numbers in the app are Clarity’s four friction rates and whatever you bind to a key result.
There is no feedback inbox. Business-Gym does not collect in-app or support feedback, so “feedback synthesis” has nothing to synthesise unless you paste the material into a Head yourself.
There is no roadmap view. The feature backlog is a table with a status column — not a timeline, a board or a release plan.
There is no native mobile app and no push notifications. Nothing pings you when a proposal appears; you go and look. Approvals, integrations and billing are web-only — who can approve, and where has the detail.
Related reading: the inbound → approve → execute loop for how proposals and approvals work everywhere else in the platform, and the same picture for sales and finance.