Abstract — Turning an evolving product vision into a working MVP

Abstract started with a broad idea: help people turn information they find online into organised knowledge that could be understood and shared.

But the vision kept moving. The name changed, the scope changed and even the central object in the product changed while the MVP was being built.

There was also no mature usage data yet, so we could not begin with an established behaviour or an existing funnel to improve.

The first job was therefore not to polish an interface. It was to work out what the product actually needed to be.

The original vision included source capture, research, publishing, social discovery, AI, archiving, branching, newsletters and future monetisation.

Trying to make all of that visible in the first product would have made it too broad to learn from.

After kickoff, we narrowed the first experience around a smaller behaviour: find something useful, add context, organise it, and turn it into something meaningful for someone else.

AI, monetisation, branching and more advanced social behaviours stayed outside the first prototype.

That gave us a much more useful question to explore: could collecting sources become the beginning of creating something useful, rather than another bookmarking habit?

The first prototypes focused on a small set of behaviours: • Capture a source • Add context • Organise material • Read the result and make it sharable

Prototyping also exposed a deeper question: What was the building block of the product?

A simple link was not enough. People needed to combine sources with their own interpretation and organise them into something that could form an argument or narrative.

The model evolved through several concepts before settling around clearer knowledge objects such as Sources, Abstracts and Briefs.

The terminology changed, but the underlying behaviour remained much more stable: collect trustworthy sources, add human interpretation, organise them, and create something useful for others.

AI became part of how I moved from conversations and incomplete ideas to product decisions the team could discuss and build from.

I used Granola to preserve context from calls, Miro to organise ideas, meeting notes, research and product questions, and ChatGPT to structure ideas, challenge assumptions and compare possible directions. Claude Design helped turn that thinking into flows, product documentation and interactive explorations while the product model was still changing.

This shortened the distance between a conversation and something concrete enough to discuss. Instead of waiting for every idea to become a polished design, we could make product questions visible earlier and iterate on them sooner.

Claude Design also changed the boundary between prototyping and implementation. The explorations were built in code, including components, interactions and motion, rather than as static representations of the experience.

We used /design-sync to keep the work connected with Claude Code. Instead of handing engineering a separate representation of the product, the code-based prototype could become an implementation starting point. The team could continue from the same work, refine it and make the technical decisions needed for production.

This reduced the amount of translation between design intent and implementation. Behaviour, interaction and motion could be discussed in something that already worked rather than reconstructed from individual screens or specifications.

The tools accelerated synthesis and execution, but they did not decide what belonged in the product. I still had to determine which behaviours mattered, what belonged in the MVP, where complexity was justified and what was ready to move forward.

The product needed to sit between two worlds. It had to offer the structure and efficiency of a productivity tool while giving reading and publishing enough space to feel considered rather than administrative.

That influenced how I approached navigation, typography and content hierarchy. I looked at tools such as Obsidian and Are.na for collecting and organising information, Spotify for the relationship between a library and active content, and editorial products such as The New York Times for reading rhythm and hierarchy.

The UI moved towards a quieter structure where navigation stayed around the edges and the active content became the main surface.

Once the core UX was stable enough, I explored different visual directions without changing the underlying reader structure. Typography, colour, spacing and editorial tone could change while the interaction model stayed consistent.

As collaboration became more important, the MVP evolved into a workspace organised around three areas: Library for sources, Briefs and the wider workspace; Workspace for research, writing and creation; and Collaboration for comments and contextual feedback.

The active content remained the main surface, with navigation and collaboration available around it when needed. Shared Briefs and contextual comments brought collaboration into the research experience rather than making it a separate part of the product. Other ideas such as Context Packs, branching and broader social functionality remained part of the future direction instead of being forced into the MVP.

Design and engineering worked in parallel rather than through a separate handoff phase.

As the interaction model and visual direction became more stable, engineering was already building authentication, content models and creation flows. Shared Briefs, contextual comments and further interface refinements were added before launch.

Abstract moved from an evolving product idea into a working production MVP. It had a clearer interaction model for capture, organisation, editing and publishing; a reusable visual language; a workspace for research and collaboration; and foundations that could absorb changes in the product vision without requiring the interface to start again.

The meaningful outcome was getting an idea into a product the team could understand, build and put in front of people.

The biggest lesson was not that AI made the work faster. It was that when execution becomes faster, judgement becomes more important.