The story of Aligned began in 2018, before the pandemic reshaped our work landscape. Its genesis was rooted in comprehensive research aimed at uncovering the fundamental workplace challenges. The breakthrough insight revealed the pervasive frustrations stemming from workplace meetings. This revelation ignited a dual mission: to address the existing deficiencies in software solutions and to devise effective strategies for mitigating these issues.

The research program combined qualitative and quantitative methods deliberately — each one designed to answer a different type of question. Twenty in-person interviews gave me the texture of the problem: the specific frustrations, the workarounds people had built, the things they'd given up on. Five hundred survey respondents gave me confidence that what I was hearing wasn't an edge case. Pricing prioritization research helped me understand what people would actually pay for, not just what they said sounded useful. Feature prioritization exercises forced tradeoffs. Emotional resonance testing — a methodology I'd been developing across projects and have since built into a standalone research tool — measured how people felt about specific concepts, not just what they thought of them. Together, these methods produced something more useful than a list of feature requests: a clear picture of what mattered most and why.

The research didn't produce a wishlist — it produced a hierarchy. Three things rose clearly to the top, and each one came from a specific user with a specific pain:

Makers wanted to protect their focus hours. Not fewer meetings necessarily, but predictable, uninterrupted time to do their actual work. This was the single most emotionally charged finding in the qualitative interviews.

Managers wanted to assign and track action items. They were losing accountability between meetings — decisions made, tasks agreed to, and then nothing. The follow-through problem was costing them real time and real trust.

Neither group wanted another app. Adoption friction was a top-of-mind concern before the product even existed. Any solution that required users to change their workflow would fail before it launched. That finding drove the Chrome extension strategy directly — the product had to go to users, not the other way around.

These three outputs didn't just inform the design. They were the product strategy.

The research clarified two distinct users who experienced the meeting problem in opposite ways. The Manager persona treated meetings as the primary medium of their work — coordination, decisions, accountability. Meetings were where things happened. The Maker persona experienced meetings as interruptions — necessary at times, but constantly threatening their ability to do the deep work their role actually required. These weren't arbitrary segments. They mapped directly to Paul Graham's widely-recognized framework, which the research validated independently. Designing for one without the other would have produced a product that worked for half its users and alienated the rest.

With the personas and core value propositions defined, the next question was how the product would grow. I mapped the natural collaboration loops already present in the meeting context — meeting invitations, discussion topic tagging, action item assignments, agenda requests — and identified which of these could double as growth mechanics. Every time a user tagged a colleague or sent a meeting card, a non-user was touched by the product. That's a growth loop built into the core workflow, not a referral scheme added later.


On the revenue side, I evaluated three models: B2B direct, bottoms-up SaaS, and freemium. The bottoms-up approach fit best with the adoption strategy — let individual users find value first, let the product spread through teams organically, then convert at the organizational level. The research had already told us that top-down mandates for new tools were a non-starter. The pricing model had to match that reality.

With the problem and user personas in sharp focus, we shifted our gaze to revenue and growth models. Our considerations spanned Business 2 Business-Consumer, Bottoms-up SAAS, and a freemium pricing model, setting the stage for Aligned's evolution.

With a clear strategy in place, the prototyping phase was about stress-testing the execution — not exploring open-ended possibilities. Each prototype scenario mapped directly to a validated research finding: protecting focus hours, assigning and tracking action items, requesting agenda details, adding preparation instructions. The goal wasn't to discover new problems at this stage. It was to find out whether the proposed solutions actually worked for the people who had the problems.

The decision to build Aligned as a Chrome extension came directly from the research — specifically from the finding that neither Managers nor Makers would adopt a standalone tool that required them to change their existing workflow. Building a React app that drops into an iframe alongside Google Calendar solved for that adoption barrier at the architecture level. The same codebase also powered a standalone responsive web app, so users who preferred that path weren't excluded. The technical implementation followed the behavioral insight. That's the order it should always go.

Research rarely gets credit for the things it prevents. This program prevented Aligned from being built around the wrong features, for the wrong users, with the wrong adoption strategy. What it produced instead was a product with a clear core value for each persona — focus hour protection for Makers, action item accountability for Managers — and a distribution strategy designed around the one thing both groups agreed on: they weren't changing their workflow for any tool, no matter how good it was. Every major product decision that followed traced back to something a real person said in an interview or marked on a survey. That's what good research is supposed to do.