A shared workspace for the next experiment

A small product team can collect plenty of information and still struggle to decide what to try next. Interviews live in one place, customer requests in another, and a weekly meeting becomes a tour of open tabs. A GrowBy workspace could give that team one route from an observed problem to a small experiment and a recorded decision. The first product would serve teams that already talk to customers but lose the connection between what they hear and what they ship.

Start with the handoff that keeps breaking

I would begin by watching the handoff between a customer conversation and a product decision. A founder might hear that new accounts abandon setup when they cannot invite a colleague. The team mentions it in chat, creates a task and later forgets which customer supplied the example. The workspace could keep the observation, the proposed change, the owner and the outcome together. That is a useful first workflow to demonstrate in a short product session.

The initial buyer could be a founder or product lead at a small software company. Their job is to make a few meaningful decisions each week with limited time and incomplete information. The offer could be a shared experiment board with linked customer evidence and a weekly decision view. A clear first version would let a user record an observation, choose a question, assign a test and return with what happened.

Build around a decision record

An experiment record needs a few fields that earn their space. What did someone observe? Which customer situation does it concern? What question is the team trying to answer? What change will be tested, and who will do the work? Before the test begins, the owner should also write what evidence would lead to continuing, revising or stopping. That turns a hopeful activity into a decision the team can revisit.

For example, a team could test a shorter invitation flow with a handful of new accounts. The record would link the original support conversations, describe the changed screen and preserve the test conditions. The review would separate observed behavior from interpretation. If people still fail at the same step, the next question might concern permission or terminology rather than the number of fields. The product should make that distinction easy to record.

Research method matters here. Nielsen Norman Group maps research methods to the kinds of questions they answer, including the distinction between reported attitudes and observed behavior. A GrowBy workflow could use that distinction in its evidence labels, so a team can see which records contain interview comments and which contain observations from actual use.

Make a useful weekly view

The weekly screen could show three things: decisions ready to make, tests still running and unresolved questions that need evidence. It should be possible to read that screen before a meeting and understand where help is needed. An overdue item is more useful when it states the obstacle. “Waiting for access to the onboarding session” tells a teammate what action to take. A red status dot alone does not.

A first release could deliberately keep integrations light. Teams could paste a source link, attach a short observation and export the decision history. Before connecting a large number of tools, the founder would learn which sources users actually return to. Access controls deserve attention from the beginning because a customer conversation can include personal or commercially sensitive material. Teams need a way to keep raw material restricted while sharing a concise, appropriate summary.

Reach teams through a visible working example

Distribution could begin with a short demonstration built around one realistic experiment, using invented sample data clearly labeled for demonstration. A product lead should be able to follow the complete sequence from a question to a decision. The founder could share that example in relevant product communities, invite a small pilot group and ask each team to use it in an actual weekly review. A practical worksheet could also introduce the workflow before someone creates an account.

The pilot should observe the whole routine. Does someone enter evidence during the week? Can another person understand it later? Does the team use the decision screen without the founder present? A user who logs in once is different from a team that brings the workspace into its regular meeting. Those behaviors would guide the next product choice and any eventual pricing structure.

Give the first product room to develop

The product could later add a searchable evidence library, recurring review templates or a portfolio view for several teams. Each addition should follow a repeated customer need. The GOV.UK guidance on understanding user needs offers a useful discipline: keep investigating what people are trying to accomplish throughout development. For this concept, that means returning to real team decisions as the feature list grows.

GrowBy suits the founder who wants a company identity broader than an experiment tracker while keeping the first workflow concrete. It can appear on the first invitation email, the shared review screen and the materials used to introduce the product. The founder could begin with one working team and carry the same identity into a more capable workspace.