Summary
Ghostpen started with a simple idea: bring in something you already have — an idea, recording, document, link or existing content — and turn it into useful work across different formats.
We built that foundation across source capture, generation, voice, editing, review and saved work.
As the product became more capable, the bigger question became clearer.
Ghostpen could do many things, but we still needed to decide what it should do exceptionally well.
That became a large part of my role as Product Lead. I was not only designing the experience; I was also shaping product direction, roadmap priorities, cross-team alignment and what we needed to measure before expanding further.
The biggest shift was moving away from how many things Ghostpen could generate and focusing on one clearer workflow:
Take useful source material, understand it properly, turn it into a connected body of work, review it, approve it and make it easy to reuse later.
Outcomes
Outcome Snapshot
A clearer product direction
Ghostpen moved from:
many inputs → many AI capabilities → many outputs
towards:
source → direction → connected work → review → reuse
A clearer product model
Instead of treating everything the AI produced as another response, we started thinking about the product around four main things:
Source
Campaign
Artifact
Decision
That gave the team a much clearer way to think about how the product should behave.
A more focused roadmap
We became more disciplined about asking whether a feature actually improved:
- Capture
- Completion
- Acceptance
- Review
- Approval
- Continuity
- Reuse
- Trust
- Repeat usage
If it did not help us understand or improve one of those things, it did not automatically need to be built.
Better alignment across the product
Web, mobile and backend had to stop feeling like separate products that happened to share a brand. We started aligning them around the same core workflow and product model.
Release validation
As part of preparing the product for release, I led validation across the staging environment.
542
authenticated checks
0
failed requests
I treat this as evidence that the product was technically ready within what we tested. It is not the same thing as saying users love the product or that we have product-market fit.
Solution
The Solution
Ghostpen became easier to define once generation stopped being the whole product.
Use what the person already knows.
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:
Capture
The user brings the source into Ghostpen in the form it already exists. The idea is to reduce the amount of work needed before the product can be useful.
Understand
Before generating anything, Ghostpen needs to understand the source: the main argument, important claims, audience, voice and anything that needs clarification. The user can correct that interpretation before moving on.
Frame
Once the source is clear, Ghostpen helps the user decide the direction, audience, objective, channels and the few outputs that actually make sense. I did not want the product to throw 20 options at someone just because it could.
Produce
Once the direction is clear, Ghostpen creates the individual pieces. Each one still needs to fit its channel. A LinkedIn post should not just be the first paragraph of an article.
Review
The user can edit, refine, regenerate parts, review warnings, approve or reject. One thing I cared about here was making sure AI did not quietly become the final authority. Ghostpen can help. The user still decides.
Continue
The work should not disappear after one session. The Library lets users return, continue, reuse and move approved work forward without rebuilding the same context each time.
Context
Context
AI has made first drafts much easier. I do not think the first draft is the hardest part 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 harder part is what happens around the draft: finding the useful idea, checking claims, keeping the person’s voice, adapting it for different channels, reviewing it and finding it again later.
That work is usually spread across several tools: recording, transcript, AI draft, document, feedback and publishing all live in different places.
The problem is not that those tools are bad. It is that the user keeps carrying context between them.
That was the part of the problem I became most interested in.
Problem
The Problem
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.
Who is actually hiring Ghostpen to do what?
Until we could answer that properly, more features were not necessarily making the product better. We needed the product direction to start driving the technology, not the other way around.
Research
Research & Findings
I kept separating three things:
what we had already built,
what users may actually value,
and what was simply possible.
Those are not the same thing.
We already had a strong technical base
Ghostpen already supported useful capabilities across source capture, generation, voice personalisation, editing, quality review, Library, scheduling-related flows, mobile, collaboration and multiple content formats. So the problem was not that there was nothing there. The question was how to turn that capability into a more focused product.
Generic generation was becoming less valuable as a differentiator
AI tools were getting very good at writing posts, emails, articles and scripts. That meant we could not build the product around "Ghostpen can generate content." Almost every serious AI product could do that.
What is still difficult even when generation is easy?
My answer was the work around the generation — understanding the source, keeping the context, managing the decisions, keeping multiple outputs aligned, reviewing the work, coming back to it later.
"Anyone who creates content" was too broad
We also needed a better customer hypothesis. We started narrowing the first audience towards independent experts, founder-led businesses and small professional-services teams — people who already have valuable knowledge but do not always have the time or team to consistently turn that knowledge into useful content.
This is still a hypothesis. Choosing a target customer is not the same thing as proving the market.
Goals
Goals
User goal
Help people turn knowledge they already have into useful work without constantly rebuilding context.
Product goal
Create one connected journey from source → direction → production → review → approval → reuse.
Business goal
Understand whether this is a problem people experience often enough, value enough and will pay to solve.
My product leadership goal
Move the team away from "What else can we build?" towards "What should we build next, and what do we expect to learn from it?"
Constraints
Constraints
One of Ghostpen’s biggest constraints was how much we could build. There were too many possible directions.
Product breadth
The system could support more options than a new user should ever have to deal with. So part of the work was deciding what should stay in the background and what needed to be part of the main experience.
AI can sound right even when it is wrong
A fluent answer is not always an accurate answer. That meant users needed to be able to review interpretations, make corrections, edit generated work and approve important changes.
Web, mobile and backend were not always at the same point
Different parts of the product had been built at different times and for slightly different assumptions. I had to help bring them back towards one product direction.
Mobile needed its own role
Trying to put the whole desktop product on a phone would have created a lot of complexity. We needed to be more deliberate about what mobile was actually good for.
Reliability
Ghostpen depends on AI providers, uploads, transcription, voice and external integrations. All of those introduce failure states. It was not enough for a feature to work during a good demo.
Commercial validation
This was the biggest constraint: a technically strong product can still fail commercially. I did not want us to confuse “we built it” with “people need it.”
Key Decisions
Key Decisions
Decision 01
Stop using output count as a measure of product strength
At one point, it was easy to talk about Ghostpen in terms of how many different formats it could generate. But most users do not need every format. They need the right few things.
What I changed
I started pushing the product towards intentional packages instead of maximum output volume.
Trade-off
The product may look like it does less. But what it does becomes easier to understand, complete and measure.
The right package is more useful than more output.
Decision 02
Make the source more important than the prompt
A lot of AI products begin with a blank box. I did not think that should be the centre of Ghostpen. The user often already has the material. The product should help them use it.
What I changed
We started treating the source as a first-class part of the product. The source could be a meeting, recording, interview, document, video, URL, voice note or idea.
Start with what the user already knows.
Decision 03
Treat generated work as something that can live beyond the conversation
I did not want useful work to disappear inside an AI chat. A good output should have a life of its own.
What I changed
We started structuring Ghostpen around four main objects:
Source
Where the information came from.
Campaign
What we are trying to say, to whom and why.
Artifact
The actual piece of work.
Decision
What the user approved, rejected or changed.
Chat can help someone think. But the real work should not depend on finding an old message inside a conversation.
Decision 04
Keep the human in control
Ghostpen can do a lot with AI. But I did not want the AI to quietly become the owner of the work.
Ghostpen can:
- Understand
- Recommend
- Generate
- Evaluate
- Suggest
User still controls:
- Important edits
- Approvals
- Publishing
- Memory
- Consequential changes
What I changed
The point of AI here is not to remove the person. It is to reduce the amount of unnecessary work around their judgement.
AI assists. The user decides.
Decision 05
Give mobile a clear job
The easiest thing would have been to keep trying to make mobile match desktop. I did not think that was the right goal. Mobile is useful for different reasons — people have ideas while walking, they record meetings, they want to quickly review something, they want to approve work away from a desk.
What I changed
I narrowed the mobile role around:
- Capture
- Lightweight framing
- Review
- Approval
- Library
- Resume
- Continuity
Deeper production work can still be better on a larger screen. That is not a limitation to hide. It is a product decision.
Decision 06
Keep Room useful without turning Ghostpen into Slack
Collaboration matters in Ghostpen. A founder may have the idea. A marketer may shape the campaign. Another person may review the final work. The question was not whether people should collaborate. The question was how far we should take it.
What I changed
Room should support collaboration around the work already happening inside Ghostpen — people can contribute context, review, discuss, resolve decisions and help shape the work. But Room does not need to become another general workplace communication product.
That boundary matters because otherwise Ghostpen could very easily turn into several different products at the same time.
Decision 07
Be explicit about what we are not building yet
This became one of the most useful parts of the roadmap. We deliberately pushed back on things like:
- Becoming a general AI chatbot
- Exposing every possible output format
- Building a full video editor
- Becoming a project-management product
- Autonomous publishing
- Full mobile parity
- Large enterprise administration before demand exists
These are not things Ghostpen can never do. They are things the product has not yet earned the right to prioritise.
What I changed
Instead of "Can we build this?" we started asking:
Why should we build this now?
Process
Design Process
My work on Ghostpen moved between strategy, product structure, design and delivery. It was not a straight research-to-Figma process.
Product definition
I worked on customer definition, product direction, roadmap, product principles, scope and priorities.
Capability audit
I started separating capabilities into Current (built and working), Partial (some of the experience exists, but the full user journey is not complete), Target (part of the product direction, but still needs work) and Deferred (useful later, but not necessary for what we need to prove now). A screen existing does not mean the experience is complete. An API existing does not mean the product is ready.
Product architecture
I worked with the team to bring the experience around shared concepts like sources, campaigns, artifacts, approvals, revisions and continuity. That gave web, mobile and backend a more consistent product model.
Interaction design
A lot of the interaction decisions came back to one question: how much should the system do for the user before it needs them to decide? That pushed us towards progressive disclosure, fewer decisions at once, clear product states, clear next actions, recoverable errors, explicit approval and editable AI work.
Delivery
I stayed involved after design through implementation, technical feasibility, requirements, QA, validation and release readiness. Some of the best product decisions came from what we saw working in the product, not just in Figma.
System
System & Scalability
I eventually started thinking about Ghostpen through six connected layers.
Capture
How knowledge enters Ghostpen.
Intelligence
How Ghostpen understands what the source means.
Production
How that understanding becomes useful work.
Governance
How the user reviews, edits and approves what AI has done.
Operations
How the work gets saved, resumed, reused, exported or published.
Learning
How approved information can make future work easier.
If a feature did not make one of those parts meaningfully better, it probably did not need to be a priority.
Continuity
Designing for Continuity
Continuity became one of the biggest ideas behind Ghostpen. I think about it in three ways.
Within one campaign
All the pieces should still feel like they came from the same idea. If the core argument changes, the other artifacts should not continue using the old version.
Across time
A user should be able to leave and come back without trying to remember what they were doing. The product should make it clear what happened, what is finished, what still needs attention, what was approved and what comes next.
Across future work
The product can also learn from things the user has approved — Voice DNA, accepted language, audience information, previous edits, reusable source material. But I do not believe that should happen invisibly. The user should understand what Ghostpen remembers and be able to control it.
Ghostpen should remember the things that make future work easier, with the user's permission.
Collaboration
Collaboration & Delivery
As Product Lead, I worked across product, design, web engineering, mobile engineering, backend engineering, QA and commercial priorities.
A lot of the work was making sure the same product decision made sense across users, design and engineering:
What the user needs
What the product should do
What engineering can reliably support
What is important enough to build now.
That was especially important because Ghostpen already had quite a bit of technical capability. Sometimes the right product decision was not "We need another screen."
The underlying workflow needs to change so the screens we already have actually work as one product.
That was a big part of how my role changed on Ghostpen.
Testing
Testing & Launch Readiness
I wanted “done” to mean more than a screen existing, an API responding or a demo working.
The product needed to hold up across authentication, uploads, source processing, generation, editing, Library, state changes, interruptions, approval and error recovery.
542
authenticated checks
0
failed requests
That gave us confidence in the technical quality of what we tested. I still would not call it product success; that has to come from user behaviour.
Metrics
Measuring Product Value
I also wanted us to stop treating capability numbers as product success. Formats, sources and generated assets tell us what Ghostpen can do, not whether users value it.
So I started defining success around behaviour.
Activation
Not 'someone created an account.' More like: someone brought in a real source and got something useful enough to keep.
Time to First Usable Output
How quickly can the user get from source material to something they actually want to use?
Acceptance
Does the user keep, approve, export or publish the work? Or do they keep regenerating until they leave?
Completion
Do users finish what they started?
Continuity
Do they come back and continue previous work? Do they reuse old material?
Repeat usage
Does Ghostpen become part of the way they regularly work?
Those behaviours matter more to me than how many things the AI generated.
Outcomes
Outcomes
Ghostpen is still evolving, so I do not want to pretend every commercial question is answered. The clearest outcomes so far are in the product direction and how we make decisions.
A clearer product direction
The product does not need to win by saying 'We generate more things.' The stronger story is: we help people turn useful source material into connected work without losing the context behind it.
A shared product model
Source. Campaign. Artifact. Decision. Approval. Continuity. These concepts helped us speak the same language across different parts of the product.
A more disciplined roadmap
We have a better way of asking why something deserves to be built now. That has helped us say no, or at least not yet, to things that would otherwise keep increasing product scope.
Separating technical progress from commercial proof
Ghostpen can become more technically capable without becoming more commercially valuable. Those are different things. Keeping them separate has made the product decisions better.
Clearer success measures
We are paying more attention to activation, time to useful output, acceptance, completion, reuse and repeat usage. That gives us a much better basis for deciding what happens next.
Still Proving
What We Are Still Proving
Ghostpen is live. People can use it. The product works. But there are still important things we need to prove.
- Do people experience this problem often enough?
- Do they complete the workflow?
- Do they come back?
- Does the continuity actually save enough work to matter?
- Will they pay for it repeatedly?
Another feature will not answer those questions. Customer behaviour will. That is the stage we are in now.
Reflection
Reflection
Ghostpen changed the question I ask most often. Earlier in my career, it was usually: how do I design this well?
Now I spend much more time asking: should we be building this at all?
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?
Build enough to test the assumption. Measure what people value. Let that decide what comes next.
Live product
Try Ghostpen
Ghostpen is a live product. You can explore the current experience directly and see how the product is evolving.
Next project
Tarjimly FirstPass AI
How I worked on a human-in-the-loop AI translation workflow that reduced translation time while keeping human judgement inside the process.