Taking an AI product from a broad idea to a product we could properly test

Ghostpen started with a simple but ambitious idea. We wanted to build a product where someone could bring in an idea, recording, document, link or existing piece of content and turn it into useful work across different formats.

We built quite a lot of that foundation. Ghostpen could work with different kinds of source material, generate different types of content, preserve a user's voice, support editing and review, save work and help users continue from where they stopped.

But as the product became more capable, another problem became obvious.

That became a large part of my work as Product Lead. My responsibility was no longer just designing the experience. I was also helping decide what the product should become, what should be on the roadmap, what we should stop prioritising, how the web, mobile and backend teams should work around the same product direction, and what we needed to measure before expanding the product further.

The biggest shift was moving Ghostpen away from being defined by how many things it could generate. Instead, we started focusing on a much clearer workflow:

The idea behind Ghostpen became much simpler once we stopped thinking about generation as the main product.

Instead of opening an empty AI chat and asking someone to explain everything again, Ghostpen lets the user start with the material they already have.

• An idea
• A voice note
• A meeting
• An interview
• A document
• A recording
• A URL
• A video
• A webinar
• Existing content

From there, the product moves through a connected journey:

AI made it much easier to produce a first draft. But I don't think the first draft is the hardest part of the work anymore.

A founder can have a very useful 45-minute conversation. A consultant may have years of useful knowledge sitting inside client calls, presentations, webinars, documents, interviews and voice notes.

The problem is what happens after that. Someone still needs to find the useful part, decide what the real argument is, work out who it is for, check the claims, keep the person's voice, adapt it to different channels, manage revisions, approve it, publish it and find it again later.

That work usually ends up spread across different tools. The recording is in one place. The transcript is somewhere else. An AI tool creates the first draft. The draft goes into a document. Feedback happens in Slack or email. Publishing happens through another product.

None of those tools is necessarily bad. The problem is that the user keeps carrying context from one place to another.

The first version of Ghostpen was broad. Very broad. We had several input types, several output formats and a growing list of things the product could do. At first, that felt like strength. But it also made prioritisation harder.

If the backend could support another format, why not add it? If mobile could support another feature, why not put it there too? If collaboration was technically possible, should we build more collaboration tools? If the AI could do another task, should that automatically become a feature?

You can keep asking those questions forever. The problem was that almost any feature could sound reasonable.

A big part of my work was separating three things:

Those are not the same thing.

One of the interesting things about Ghostpen was that technical ability itself became a constraint. There were too many directions we could take.

My work on Ghostpen was not a straight line from research to wireframes to final UI. A lot of the work happened between strategy, product structure, design and delivery.

Continuity became one of the biggest ideas behind Ghostpen. I think about it in three ways.

As Product Lead, I worked across product, design, web engineering, mobile engineering, backend engineering, QA and commercial priorities.

A lot of the work was translation. Not language translation in this case. Product translation. I had to keep connecting:

I wanted our definition of "done" to be stronger than: the screen exists, the API responds, the demo works.

The product needed to hold up across authentication, uploads, source processing, generation, editing, Library, state changes, interruptions, approval and error recovery.

One thing I wanted to change was how we talked about metrics. Ghostpen can easily produce impressive capability numbers — number of formats, number of sources, number of generated assets. Those numbers tell us what the product can do. They do not tell us whether the user cares.

So I started defining success around behaviour.

Ghostpen is still an evolving product, so I do not want to pretend we have answered every commercial question. The strongest outcomes so far are about the product itself and how we now make decisions around it.

Ghostpen is live. People can use it. The product works. But there are still important things we need to prove.

Ghostpen changed the way I think about product leadership. Earlier in my career, the difficult question was often: how do I design this well?

We had enough technical ability to keep adding things. That actually made the job harder. You can build a sophisticated product and still have an unclear product. You can have a busy roadmap and still be going in the wrong direction. You can ship a feature perfectly and still learn nothing useful about the customer.

A large part of my role became making sure we were asking better questions before we committed more time to building.

• Who are we solving this for?
• What are they actually trying to get done?
• What part of that workflow is painful enough to matter?
• What do we need to build to test that?
• What should wait?
• What behaviour would prove that the decision was right?