We made the first version seller-controlled because that matched the design of most sales tools. Buyers could read documents and view the mutual action plan, but only sellers could add or change items. We shipped that model. Buyers barely used it.
That miss clarified something our prior research should have made clear: buyers pull away from tools that feel imposed on them. They join tools that feel shared. The idea is obvious afterward, but its product implications took much longer to resolve.
Seller Requests, Buyer Frustrations
Before building the first version, we spoke with people on both sides of complex B2B deals. Sellers consistently asked for visibility into proposal views, stakeholder participation, and a single link instead of scattered attachments. That feedback defined the initial product idea.
Buyer responses varied more. Some wanted one simple place for everything in a deal, instead of six email threads and three folders. Others wanted clear expectations at each stage. Many disliked knowing that sellers had a fuller status picture than they did, describing the experience as being watched without corresponding visibility.
We chose to address that imbalance first. It was a workflow concern, not just a privacy concern. Deals with comparable visibility on both sides progressed differently: buyers engaged more, questions surfaced sooner, and both parties tracked commitments instead of leaving that work to the rep.
The Shared Ownership Gap
Sales tools usually make the rep the owner of the action plan. The rep creates the checklist and updates it after calls. The buyer may get a summary, often by email, while the plan remains in a system they never open.
That model has a clear cost. Buyers cannot track commitments that only the seller can see. An internal approval date or a security review by IT may be agreed to on a call, then remain only in the rep's notes. The buyer sees them again only if the rep sends a follow-up.
Co-ownership lets buyers add items, complete their tasks, and view the rep's work in the same place. It sounds minor, but it changed how buyers described the deal. They said it felt more like running a project together than being sold to. People participate more in processes they feel responsible for.
The challenge was sharing ownership without exposing seller-side complexity. Buyers need a clean view of what matters to them, not the deal's full CRM state. We tested the information hierarchy with actual buyers: what stays visible, what remains seller-only, and what both sides can see. Their behavior mattered more than stated preferences.
One Link for Every Deal
A foundational choice was giving every deal a single link. Not one for each document or meeting recap, but one link to the mutual action plan, files, timeline, and open questions.
This was partly a buyer-experience decision. If a seller sends five links across three email threads, the buyer's champion must organize them, identify the current version, and gather what to share internally. The burden lands on the person the seller most needs to keep involved.
One link also makes internal sharing easier. A champion can send it to a VP or procurement team, and each visitor sees the deal's current state. No version conflict, and no confusion over a proposal that changed after it was sent.
This required careful access design. People on the buyer side need different permissions: the evaluation lead needs more access than the executive approving the contract. We chose invite-based access, letting the room owner set permissions for each participant. It is not the most elaborate model, but it covers most real deals without unnecessary administration.
Why We Added the Activity Feed
An activity feed was not part of our plan. During early tests, reps kept asking about information we could see but they could not: "Did they view the proposal?" "Has anyone opened the room since I shared it?" "Which documents are receiving attention?"
Those unknowns took up rep time. They sent follow-ups without knowing whether the material in question had been reviewed. Once we showed them that information, they asked for it inside Aligned.
The design challenge was avoiding a surveillance feel. We chose a light feed showing what happened, when, and who. It is not a session-replay or heatmap dashboard, only enough context for a useful outreach decision. We also framed it for buyers as shared visibility into active items and needs, not a seller view of everything they do.
Features We Left Out
Some suggested features stayed out of the initial product. Full contract lifecycle management, with redlining and e-signature, was one. Video messages for adding context to documents were another. A full CRM with pipeline management was a third.
Each is a substantial category with strong existing tools. Small replicas inside Aligned would add complexity without making those jobs better. The deal room's value is bringing both sides to one view of the deal's current state. Duplicating other tools would make it heavier, not more collaborative.
We are not ruling out those integrations. HubSpot and Salesforce sync ships in the initial version because it closes a two-way information gap without copying CRM functions. DocuSign and similar products belong on the roadmap as integrations, not replacements. The rule is simple: add to the ecosystem rather than replace it.
What We Are Still Learning
We still have not settled how much structure should appear by default and how much teams should configure. Too little leaves teams unsure what belongs in a room. Too much can impose a template that does not fit every sales process.
Our current answer is template-optional. Aligned offers a default mutual action plan based on common deal stages, while allowing full customization. That helps teams wanting a starting point, but is less useful for teams with a process refined over years that prefer no suggested structure.
The tension is between a clear point of view and flexibility. A defined workflow is easier to adopt quickly; a flexible one suits more teams. We watch which templates our early-access cohort keeps or drops, then adjust the defaults. The right amount of structure should come from usage, not our assumptions about running deals.
That usage-based adjustment is likely to shape the product for the next several years. This workflow is only the starting point. Its direction will follow what we learn from the teams using it.