I could not find a tool that preserved the reading experience while allowing me to slightly deviate from the book and understand a subject better.

The final straw came when I was trying to better understand “Sun and Steel” using ChatGPT, and I got restricted from copy pasting.

Throughout reading the rest of the book I had to rely on taking screenshots of the book, copy the parts or the answer I wanted to save, then make custom notes in Kindle.

Inspired by Hilary Gridley’s post it’s the opposite of death by a thousand paper cuts, I thought this would be a good opportunity to see what I can build in Cursor.

I ended up making Echo: an open-source AI reading companion that lets you open a PDF, read it, annotate it, and send content to an LLM without context switching.

This is not a post about how to build the tool. It is about how to stay focused when building with an LLM IDE as a non developer.

I made a lot of mistakes during this process: reverting whole features accidentally, confusing both myself and Cursor, asking myself what Vercel is, understanding how to create tests. It started changing files I didn’t need, or changing files without understanding the upstream and downstream effects.

Why I used Cursor

If you are trying to do a fast first pass, Lovable or Bolt can get you to a visible prototype quickly. But if you are extending an existing product, or building a prototype with many moving parts, it may need to match existing product logic and support many small controlled edits over time.

This is where I found Cursor to be stronger: it let me control iterative changes across multiple files. For a founder team, this is the difference between a demo that looks right and a prototype that you can evolve.

Below are some of the things that I will do from the get-go on my next product:

Make Cursor understand what your plan is

Cursor knows what your current codebase has, not what you think or plan to do next.

If you built a product with an engineering team, they will ask you questions like “what kind of files will be uploaded here? Will we ever need to delete them or store them somewhere?”

These questions force you to think deeper about your product, and in exchange, you gain clarity. When you are first thinking about your product, you will focus on what it is. The what it is not usually comes when you get to the building phase. The answers to the latter will sometimes change the scope of the former.

One of AI’s downsides is how agreeable it is, so if you just vanilla prompt Cursor to create a file upload system you can’t guarantee it won’t try to do user management too. The goal of the scoping exercise is to stop Cursor from going into rabbit-holes and over-engineering.

Practical advice: Create a context.md file for your product and ask Cursor to interview you.

Act as a senior product engineer working with a non technical founder. I am building [tool] for [user] to achieve [outcome]. Before we write code, interview me one question at a time. Your goal is to clarify product goals, success criteria, key user flows, scope, and what is out of scope for v1. Ask about assumptions, tradeoffs, risks and operational limits. Challenge vague answers and force concrete decisions. Keep questions practical for a founder who cannot implement complex infrastructure alone. At the end, produce a brief with: product goal, success metrics, core flow, non core flow, constraints, risks, open questions, and build order. Do not suggest implementation until the brief is complete and approved.

Focus on the new experience you want to create. Build everything else only to the level needed to validate the core flow.

Use component libraries, do not create Custom CSS components unless required

Unless you are creating a whole new way to use a product, it’s likely that you will use some combination of forms, tables, buttons. I asked Cursor to use the Tailwind library and explicitly prompted not to create it’s own components unless required. You don’t want to spend time asking an LLM to tweak a table layout, but rather focus on how the table fits into your user experience.

Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know. - Jakob’s Law

If you are building a tool that is “kind of like X but better” adopt the design patterns that you see out there. Mobbin is a great resource.

Practical advice: When you are building your context file, prompt the following:

Use [library: Tailwin, Material UI etc] components for all standard elements like forms, tables, buttons, modals, and navigation. Do not create custom CSS or new components unless the core experience requires something that does not exist in the library. When in doubt, reuse existing patterns. Flag any case where you think a custom component is needed and explain why before building it.

Build only the backend depth you need to validate the core flow

Echo is open source, bring your own key, and local first. I skipped authentication and API key management because I was not planning to monetise it.

If your goal is to validate a product decision with customers, you do not need production grade backend. A mocked dataset and a believable login flow are often enough to test the core experience.

If you are not a software developer, full stack architecture through an LLM is high risk. You will not understand what broke or why. (please don’t put something that handles sensitive data if you do not understand how it works)

Practical advice: Add some version of the below in your prompting:

# Backend Infrastructure Rule

## Role
You are building a prototype where simplicity enables faster validation.

## Instruction
Before adding any backend infrastructure, check if the core flow defined in context.md can work without it.

## Preferences
Prefer:
- Local storage, file based storage, or SQLite over hosted databases
- Hardcoded or mocked data over external API calls

## Constraint
If you believe the core flow requires something beyond the above, stop and explain the tradeoff in plain language before building. Do not proceed until I confirm.

You will want to fix everything as you go. Focus.

If you are building a tool for yourself, you get instant feedback about what you like and what you do not. That feedback turns into a growing list of fixes.

One of the benefits of using LLMs to code is small feedback loops. But small loops do not mean you should fix everything as it comes up. In reality, you will get distracted and sidetracked instead of working on your core user flow.

Instead of stopping to fix layout issues or small annoyances, write them down in a fixes-and-improvements.md file. Similar to a regular product development lifecycle, there are things that need your attention now and things that need your attention later.

Practical advice: In a separate chat, add this:

When I mention a bug, UI issue, or improvement that is not critical to the current task, do not fix it immediately. Add it to a file called fixes-and-improvements.md using this format:

### [Short title] [OPEN] [BUG or IMPROVEMENT]

**Problem**: Describe what is wrong or what could be better.

**Root cause (for agents)**: Explain why this is happening, including relevant files or logic.

**Relevant files**: List the files involved and what role they play.

**Solution**: Describe the fix or improvement at a high level.

Mark items as [OPEN] when logged and [CLOSED] when resolved. Only work on items from this file when I explicitly ask you to.

Start versioning before you break something you cannot undo

As you build a more comprehensive user experience, your codebase will grow. More files, more components, more dependencies between them. At some point, you will change something in one place that breaks something elsewhere.

In Echo, tweaking the “Select your sync file” prompt when a PDF got imported broke the “Sync file” settings panel. That took about an hour to properly revert..

Once you have a first stable version of your end to end experience, start versioning. Versioning means deploying specific releases you can always reference back to when something breaks.

I asked Cursor to interview me about the core flows I wanted to protect and generate a testing pack. I added a workflow file that runs those tests before each release and deploys to GitHub with a changelog.

Practical advice: Once you have a stable version of your concept, create this in a new chat.

Create a single workflow document called TESTING_AND_DEPLOYMENT.md that you will use to set up my project and execute every time I want to commit and deploy. Assume I am not a software developer. Do not just show me commands. Execute them for me and explain what you did after each step.

The document should have two parts:

PART 1: FIRST TIME SETUP (do once, execute each step)

1. Git setup
- Check if Git is installed. If not, tell me how to install it and wait for confirmation.
- Create a new repository on GitHub for this project.
- Connect my local project folder to the repository.
- Make the first commit and push.
- Confirm each step is complete before moving on.

2. Testing setup
- Interview me about the core user flows I want to protect. Ask one question at a time.
- Once you understand the flows, generate a testing suite that covers them.
- Set up the tests so they can run with a single command.
- Run the tests once to confirm they work.
- Explain what passed or failed.

3. Workflow file setup
- Create a list of files that should never be committed (API keys, passwords, .env files, user data) and add them to .gitignore.
- Create a changelog template in CHANGELOG.md.
- Confirm setup is complete.

PART 2: EVERY TIME I WANT TO COMMIT (execute this when I say "commit" or "deploy")

Step 1: Run tests
- Run the test suite.
- If tests fail, stop and explain what broke in plain language. Do not continue until I confirm.

Step 2: Review changes
- Show me a summary of what changed.
- Flag any files that should not be committed.

Step 3: Stage and commit
- Stage the appropriate files.
- Ask me for a short description of what changed.
- Commit with a clear message using the format (feat, fix, refactor, etc.)

Step 4: Bump version if needed
- Ask me if this change needs a version bump.
- If yes, ask if it is a patch, minor, or major change, then bump accordingly.

Step 5: Update changelog
- Add an entry to CHANGELOG.md based on my description.

Step 6: Push
- Push changes to GitHub.
- Confirm the push was successful.

Step 7: Tag a release (optional)
- Ask me if I want to tag this as a stable release.
- If yes, create and push the tag.

After setup is complete, follow Part 2 every time I ask you to commit or deploy. Execute each step and confirm before moving to the next.

Closing thoughts

AI might change who writes the code, but it does not change why good software practices exist.

If you are not a software developer and someone sold you the idea of “just ask Cursor and it will do it”, that illusion breaks the first time you build a comprehensive experience end to end.

If you are building a throwaway piece, this is less important. But for a tool you plan to use and iterate on, we are relearning what software developers figured out decades ago: the boring stuff is what keeps the product moving.

Cursor might mask as your friendly engineer, but that is a double edged sword. It does not push back, and it does not stop itself from going down the same rabbit hole as you do. It will optimise for a thing you never need and then confuse itself when the codebase gets too big.

The highest leverage you can have right now is building a workflow that keeps Cursor focused on what matters for your goal.

I then spent most of the second half of 2025 going in a rabbit hole.

At some point I thought I'd fallen for the productivity gospel.

Most of the tools I tried did not stick, but a few did, and they changed how I work.

Consider this a "what's in my gym bag" post. Your setup will look different. But if you are trying to solve similar problems, this might save you some trial and error.

What was I aiming for?

I had two goals:

1. Reduce the busywork that does not move the product meaningfully forward. It was never a single blow, but rather death by a thousand cuts that had me at the point where a lot of what I was doing was a balancing act between trying not to forget things and trying to carry myself as a professional and not pump out the most awful communication, ticket or update to the team.

2. Create more space for deep thinking. The stuff you know you need to do but never prioritise because it is not urgent enough. Stephen Covey calls them the Not Urgent but Important activities.

If I was going to go down the rabbit hole, these were the specific problems I wanted to solve:

• Reduce duplicative comms (e.g. not rewriting the same update in different formats)

• Speed up output (e.g. write as fast as I think)

• Do better user interviews (e.g. be more present in interviews, spend less time synthesising)

• Avoid obvious mistakes (e.g. prevent predictable slips)

• Wear different hats when I review content (e.g. remember what I read from books and podcasts in a way I can use in my daily work)

The actual part you came for

Doing better user interviews

Concept: Automatically transcribe your interviews and use an LLM to derive commonalities and pull direct quotes
Tools: Hangouts → Gemini → NotebookLM

I use Google Hangouts as a daily driver for meetings.

For that, I use Gemini. Gemini records and gives you a transcription and an executive summary. You want the transcription.

Say you are kicking off a new initiative and interviewing five or six stakeholders.

Transcribe everything. You are going to need direct quotes to build your case later. Summaries are useful, but transcriptions are essential.

Then, you can use an LLM to summarise. This is where the risk of hallucination comes in. The tools are very good at convincing you they are telling the truth.

I ended up using NotebookLM because it cites sources. You can check every quote against the original. It is really good at pulling specific quotes and referencing the exact spot in the transcript. It can also summarise where your users agree and where they differ.

It’s also nicely integrated into the whole Google ecosystem, so you can import your transcription from Google Drive in two clicks.

It also made me a better interviewer - you kind of start interviewing for the LLM. I found myself being more focused on the other person and what they were saying. I was not fishing for insights, but trying to understand.

Where this breaks

This would usually go in a PRD, but if your content lives somewhere else, NotebookLM isn’t that good at picking up external sources that are live in another folder (let’s say Confluence). I have to keep my PRDs up to date somewhere else and manually update NotebookLM with context.

If you do not use Hangouts, there are similar solutions for Teams and Zoom. As long as you have the transcripts, you can import them into NotebookLM.

Conclusion

• NotebookLM: Amazing for interview insights where you want to pull direct quotes from without hallucinating.

Take better meeting notes

Concept: Use Granola (or an alternative) to keep a structured set of meeting notes that you can analyse
Tools: Granola

Gemini is OK at transcribing notes, but then you need to organise and file those notes yourself.

When you have back-to-back meetings all day, you can barely recall your name by the end of it, let alone what you promised a colleague or that insight you said you would write down.

I just wanted something that runs in the background and leaves me alone - Granola was a great candidate for that.

Granola makes it easy to transcribe as a default (it gives you reminders of your meetings, automatically pulling up Hangouts).

It also allows you to sort everything in folders and automatically add meetings to those folders, so it covers the gap that Gemini doesn’t, the post-meeting admin time.

I have folders for:

• Daily stand-ups

• 1:1 meetings

• Project-specific meetings

It also has a super cool thing (which I don’t use enough) called Recipes. Basically quick-trigger prompts to analyse your transcriptions and output an answer.

You can use Granola in 3 major ways:

1. Deep-dive into the last meeting

2. Deep-dive into the current folder (eg: all the meetings I had with my manager)

3. Deep-dive into all your notes (eg: what did I talk about this week)

There is a fourth: ask what you missed while zoning out in a live meeting. Just ask “What did I miss in the last X minutes”

I use it to:

• Understand common themes that I might’ve not picked up on (for example, who was not engaged in that meeting that I need to pay close attention to managing?)

• Generate follow-up points (for example, after the stand-up I can easily share what I aligned with the team on in that morning)

Granola also has a custom recipe creator (similar to a prompt that you can quickly trigger).

I have a custom Recipe for my daily stand-up notes: I run it after the stand-up and it gives me the 2-3 action points we agreed on for the day that I can then post in the Slack group and review the next day with the team.

Also, if I zone out and get distracted I can always review the transcript.

Where this breaks

• It doesn’t have an official MCP server so it was not as straightforward to pull content into Cursor or any other tool. You can hack around it with unofficial MCP servers but I didn’t bother yet.

Conclusion

• Granola: Daily driver for any meeting. Super easy to understand what was talked about. I want to test it to see if I can replace NotebookLM for direct quoting users, but I’m still toying with that.

Type as fast as I think

Concept: Use a speech-to-text tool to communicate better
Tools: WisprFlow / WillowVoice (there are others, these are the ones I tested)

I work remotely. And my day is a mix of people asking me things in meetings and people asking me things in writing.

For the people asking me things in meetings, I was naturally creating context around my answer, providing reassurance, asking the person relevant questions back.

But after a long day, my answers in writing tend to be monosyllabic. Which does not help my case, since writing is the modality that has the biggest potential to be misunderstood and the meaning distorted by the mood of the reader.

Especially when people reached out with concerns, I wanted to go the extra mile to answer without the extra effort.

There are a lot of startups in this space. Fortunately, they built for the operating system rather than the browser. I tried Willow and Wispr, I really liked them both.

The way this works is:

1. You have a hotkey on your keyboard.

2. You keep it pressed.

3. You speak into your microphone.

4. The tool takes your transcription, runs it through some LLM, and then just pastes it in whatever field you have in focus at the moment.

It doesn’t really matter if it’s a Chrome tab or a Cursor window. Anywhere where you can focus and type is a place where you can paste this content.

If you live with someone, you have to get used to talking by yourself in short phrases. If anyone is around you just let them know that you might say some weird corporate stuff during the day and that they should not hate you for it

Conclusion

• I use this daily. The tools are similar enough that I would just pick one and try it. I went with Wispr because it had a Windows version when I switched laptops, but both of them offer Windows and Mac options now.

The mothership: Cursor

Concept: Use Cursor to better product thinking and strategic decisions
Tools: Cursor

I spent months rolling my eyes at non-developers using Cursor.

Then I hit the limits of ChatGPT and Claude. The context window fills up. Conversations get slow. You cannot easily switch models. And there is no clean way to keep your thinking organised across sessions when dealing with a product portfolio that spans interviews, insights, hypotheses and large datasets.

The most important benefit of Cursor is not better writing, but better thinking.

Cursor is not just for writing better tickets. It is for structuring your thinking and seeing it through different lenses until you spot the gaps.

It is a bit of a learning curve if you never used a code editor. A friend recommended https://cursorforpms.com which teaches Cursor inside of Cursor. Tal Raviv runs a free Maven workshop [here] that shows what Cursor can do for non-developers.

You can structure your context in files and folders. You can run the same idea through different lenses until you spot the gaps. You can switch models without losing everything.

What does that mean?

Here is how I set it up:

I have a folder for my initiative. In that folder, I have:

• A file that explains the context of the company and the market

• A file that explains the concept (concept.md)

• A file that has insights from customer interviews (customer-interview.md)

• A file that has a data export of current analytics (Q1-analytics.md)

Then, I have a top-level set of instructions:

• A file that says how it should think about the product (agents.md, devils-advocate-strategy.md, red-team-blue-team.md)

• A file that highlights a few output formats (prd.md, executive-summary.md, weekly-updates.md)

• Another folder that asks the LLM to simulate different perspectives (engineer.md, busy-senior-executive.md, user-researcher.md)

Then, I can take Cursor and say:

• Review @concept.md and output an executive summary for my boss in the format of @executive-summary.md

• Review @concept.md using the @busy-senior-executive.md

Here is an example prompt (skip if you just want the takeaway):

# Executive Reviewer - Strategic Business Perspective

You are reviewing this PRD from the perspective of a seasoned executive (VP or C-level) with 15+ years of leadership experience at high-growth tech companies. You think strategically about business impact, stakeholder alignment, and organizational priorities.

## Your Review Focus

When reviewing this PRD, provide:
- **Strategic framing and business context** - How does this connect to company goals?
- **Business impact assessment** - What's the ROI? How do we measure success?
- **Resource allocation perspective** - Is this worth the investment?
- **Risk assessment from a business lens** - What could go wrong strategically?
- **Stakeholder implications** - Who needs to be aligned? What dependencies exist?

## What to Look For

Review the PRD for:
- Clear connection to company strategy and OKRs
- Compelling business case and ROI
- Well-defined success metrics (not just vanity metrics)
- Resource requirements and justification
- Cross-functional dependencies and stakeholder impact
- Competitive positioning and market differentiation
- Organizational risks and change management needs
- Clear decision points and what you're being asked to approve

## Communication Style

- **Clear and concise** - Executives are busy, respect their time
- **Focus on outcomes and impact, not process** - What changes, not how
- **Connect work to business goals and metrics** - Always tie to OKRs/strategy
- **Flag organizational risks and dependencies** - What blockers exist?
- **Think about cross-functional implications** - Who else is affected?

## Review Structure

Organize your feedback as:

1. **Strategic Alignment** (How does this fit our strategy?)
   - Connection to company goals and OKRs
   - Market positioning and competitive angle
   - Long-term strategic value
   - Opportunity cost (what else could we build?)

2. **Business Impact** (What's the expected value?)
   - Revenue impact or cost savings
   - User growth or engagement metrics
   - Market differentiation
   - Success metrics and how they'll be measured

3. **Resource Requirements** (Is this worth the investment?)
   - Team commitment (eng, design, PM time)
   - Timeline and milestones
   - Budget considerations
   - ROI assessment

4. **Risks & Mitigation** (What could go wrong?)
   - Business risks (market timing, competition)
   - Execution risks (scope creep, dependencies)
   - Reputation or brand risks
   - Mitigation strategies

5. **Stakeholder Considerations** (Who's affected?)
   - Cross-functional dependencies
   - Change management needs
   - Customer communication plan
   - Internal alignment required

6. **Recommendations** (What should change?)
   - Strategic framing improvements
   - Areas needing stronger business justification
   - Risk mitigation strategies
   - Phasing or scope adjustments for better ROI

7. **Open Questions** (What needs clarification?)
   - Missing business context
   - Unclear success criteria
   - Resource assumptions to validate

Conclusion

There is an “aha” moment with Cursor, similar to riding a bike, where you just get it. It is worth pushing through. If you have never tried Cursor before, try cursorforpms.com. You should be able to do it end to end in 3 to 4 hours.

Hot tips:

• You can use the LLM to help create your instruction files. Prompt something like: “I am a product manager in X industry. Interview me and ask anything you need to understand my goals, the domain I work in, and my communication style. At the end, create an agents.md file I can use to review my work.”

• If your company uses an enterprise LLM, you can plug in a custom API key. That way all your data stays within your company’s security policies.

• Once you get the basics, learn about MCP servers. (I describe them to colleagues as sort of like an API, but experienced devs might cut my head off, so here is the official definition.) You can hook them up to Confluence and Jira and pull content from it.

How much does this cost?

I pay for ChatGPT, Granola, Wispr and Cursor, at a total of about 60 something euros per month.

In my case, the value was justified in what I got back (time and perspective) but there is some space for cost optimisation. For example, I saw people using VSCode + Cline instead of Cursor, but I opted for a fast set-up time.

I still use vanilla ChatGPT for quick questions or quick re-writes.

That’s it

None of these tools are perfect. They will keep changing. But the core problems will not: too much admin, not enough space to think.

If you have found something that works, let me know.

Most people react in two ways: they either over-apologize and look unreliable, or they deflect and look defensive. Both reactions destroy trust in different ways.

When someone is upset about something you did wrong, they’re not just processing the mistake itself. They’re deciding whether they can still trust you.

The ideas below come from “Never Split the Difference” by Chris Voss, a former FBI hostage negotiator.

I had it on my reading list for a while, and in an attempt to remember more from the books that I read, I am trying to distill one or two concepts per book that I can actually apply in my day-to-day life.

One important aspect: The goal isn’t to manipulate or to ‘win’ because you were right.

“The person in front of you is not the problem. The unresolved issue is.”
- one of the quotes that resonated with me from the book

Here’s what works for me. I hope you take whatever works for yourself and discard the rest.

Before the meeting

Spend five minutes writing down what happened. Focus on how it affected them.

• What exactly went wrong?

• Who was affected, and how?

• What might they be thinking or feeling right now?

• What outcome do they hope for?

Examples:

• I missed the deadline, which delayed their project and made them look unprepared in their meeting.

• I made a decision without input, which probably made the team feel sidelined.

This work matters because it lets you enter the meeting one step ahead. Not just ready to explain yourself, but already thinking about what they’ll need to feel the issue is resolved.

In the meeting, name what they might think and how they might feel

After you’ve joined the meeting and thanked them for their time, you can start naming their concerns.

I usually open with one of the two:

• “I wanted to talk about what happened earlier and understand how it affected things.”

• “I realise this didn’t go as expected, and I’d like to make sure we deal with it properly.”

Chris Voss calls these two concepts accusation audit and emotion labelling.

• Accusation audit disarms the tension (“I know this looks bad”).

• Labelling validates the emotion underneath (“It sounds like this caused a lot of frustration”).

Instead of waiting for them to think “This person doesn’t understand the impact” or “They’re trying to minimize this” you name those concerns first.

Say you missed a deadline that blocked someone else’s work. You might start with:

“It seems like this put you in a tough spot because you were counting on it to move forward.”

This is the accusation audit. You’re naming the likely thought: “I can’t rely on you.”

Then you follow with the labelling, which acknowledges the emotion behind that thought:

“It sounds like that’s been frustrating to deal with.”

Or maybe you made a decision without consulting the team. You could say:

“It seems like you’re concerned this sets a precedent where decisions get made without input.”

Then add:

“It sounds like that felt discouraging, especially since you were expecting to be involved.”

When you name their concerns before they have to voice them, you show you understand the real impact, not just your own perspective.

This gives them control to confirm or correct what you’ve said, which makes them feel heard rather than defensive.

I know I’ve labelled the right emotions when the other person nods while I speak.

If you’re wrong, they’ll correct you. They would say “Yea, not only that, but also…”

You’re not trying to make them feel better about you. You’re trying to make them feel understood about the problem.

That shift is what maintains your credibility. People trust those who can see the situation clearly, even when it reflects poorly on them.

(side-note) When I heard about an accusation audit, I instantly thought about the final rap scene in 8 Mile where Eminem lists out all the things his opponent might say about him next. You’re taking the sting out by naming it first.

(back to our topic)

Ask them how this affects what they care about

If the previous steps worked, they should feel more understood. This will open them up to a discussion.

This is where you can shift the conversation from blame to problem solving. If they’re still defensive, go back and name more concerns or label more emotions. Don’t move forward until they feel heard.

Examples:

• “In terms of where we are right now, I wanted to align on the biggest challenge this creates for you?”

• “How does this impact what you need to deliver?”

These questions do three things:

1. They show you care about the actual impact, not just your own explanation.

2. They give the other person control over the conversation.

3. They move the conversation toward working together on a solution and surface information you need to fix the problem, not just apologize for it.

I tend to start with:

• “Here’s what I propose we can do to get back on track and how we might stop this from happening in the future.”

End on clear next steps

After they felt understood and you aligned on next steps, I find it important that the other person doesn’t feel like I just sweet-talked them.

At this point, I want the other person to come out of the meeting emotionally relieved but with a clear plan for next steps. If they need to report upwards, you don’t want them saying, ‘We don’t have a solution, but I feel much better now.’

Here’s how I’d phrase it:

• “Let me play this back to you to make sure we’re aligned. To confirm, the next steps are that I’ll do X and Y. I’ll follow-up on X and Y by [add specific date]. How does that sound?”

The aim is not to avoid any consequence

The goal isn’t to erase the mistake. It’s to show that you understand the real impact, can handle conflict without flinching, and care more about fixing the problem than defending yourself.

What ideally the other person would come out of the meeting understanding is that:

1. You understand the real impact, not just your own perspective.

2. You can navigate difficult conversations without getting defensive.

3. You focus on solving problems, not protecting yourself.

It might take time for the relationship to fully reset, but doing the audit and labelling opens the path for that to happen. If you skip this part and just fix the problem, you risk planting quiet doubts about whether you’ll take responsibility next time, especially if the stakes are higher.

I’m not saying you shouldn’t apologise. I’m saying that if you rely on an apology and time to solve the problem, you’re not doing yourself any favours.

If software is eating the world, then the builders of software are the ones shaping the new roads and railways. They’re not just building software.

In healthcare, education, defense, social care and other core industries, it shapes policy, perception and trust. They set precedents. They influence legislation. They affect what people believe it’s possible, and even more, what they fear. When a company does something shady, it's not just that company’s reputation at stake. It erodes public trust in the entire system.

This isn’t abstract. In the UK, the Post Office's Horizon software falsely flagged local branch workers for financial misconduct. Over 700 people were prosecuted based on faulty digital records. Some went to prison. This is not the only example.

Unlike concrete or steel, software should be reversible. But in these domains, that’s not often the case. Other industries can design around vendor lock-in. But in our industry, procurement cycles are long. Changing platforms means retraining thousands, re-integrating data, and rewriting processes.

The people using your software? They’re not the executives buying or comissioning it. They’re not opt-in users. They’re nurses, teachers, caseworkers - working often in understaffed departments with no alternative tools They didn’t choose your interface, but they have to live with it. There’s a quiet reality that thousands of people may live within the constraints you define, without ever knowing your name.

When you zoom in enough, everything looks like Jira tickets and quarterly planning. When you speak up, you’re sometimes treated like friction. You won’t get promoted for asking harder questions. You won’t earn more for caring.

I don’t pretend to have a solution. There are days I wrestle with this myself.

What I want to say is: if you have the honour of working in one of these industries, care anyway. Not for the company, but for your end user.

Not because someone will notice, but because someone will have to live inside what you build.

Thank you for your time.

Subscribe now

P.S: You can find me also at https://protocoltwo.com

Some companies need vision, others need execution. Some need structure, others need speed. If you think of a company’s strengths and weaknesses as a radial graph, they will be great at some things and bad at others.

Your next company won’t have the same strengths or gaps. So you selfishly have to prepare for everything.

I believe that your goal as someone more junior in this field is to put yourself in a position where you get the chance to continue working on products. More reps give you more chances to make the mistakes that eventually make you good.

If you are a product manager, your job will include some aspect of delivery.

The people who try to run from delivery because it’s “not real product management” are missing the point. Until the product is out the door and has the business results required, it’s your duty to get it over the line.

If the company has a delivery manager, great. If not, do not stop the train. Get good at it. Get good at clarifying your thoughts into tickets, get good at making it clear for other people not only what, but why you are doing the work that you are doing.

You will be seen as reliable, as the person that “gets stuff done”. That makes you crucial to the company. Speed compounds, if you ship faster, you learn faster. If you learn faster, you become better. If you get better, you get a chance at working on bigger things.

Nobody said, “He’s a bad product manager because he’s so good at delivery.”

Product managers are a little bit of everything. This is a generalist job.

The best product managers are a little bit T-shaped. They are good at their job, but they are interested in everything around their job. Don’t try to explain to other people how to do their job, but learn the 80/20 of all the tangent departments that you work with. Other people appreciate that too: because you won’t come into the meeting asking for unreasonable things.

Read Reddit or Hacker News and understand what other departments don’t like about product management. The same respect you pay to product, the same respect other people pay to their craft.

Don’t take product management books at face value

Product management books often paint an aspirational picture of what the job should be. In this field, the grass is truly greener. Other product managers read those books and think, “This company doesn’t do that, but I bet other companies do,” and the cycle repeats over and over.

A lot of product management is improvisation, it’s fixing problems that shouldn’t be there in the first place. You need to read those books, but try to ask other product managers how their job is different. The ground will often look different from the map.

Your reputation matters

Show up on time in meetings, take notes, send action points to the team, set reminders to follow up. You don’t have to be liked to do your job, but it sure helps. You don’t have a choice not to work with people in this field. In the corporate world, you will hear a lot of “Let’s catch up about this later” or “I’ll follow up about this”. You will be amused by how many people are surprised when you do follow up.

Think about who has the power to make your life bad or good, and hold a mental compass of how you look in their eyes. You work with a lot of people, but realistically, only some will be able to influence your career.

There’s a difference between challenging bad ideas and challenging authority for the sake of it. Calling out your boss in public doesn’t always work. Criticizing in public makes people default to being on the defensive. Do not gossip about your peers.

Think like someone who has a big stake in the company’s success

One problem product managers have is tunnel vision. Juniors are often interested in how. The more senior you get, the more you will be interested in the why because the type of problems you deal with will be bigger.

A junior product manager who discusses business goals and can draw a reasoning line between their work and the goal is seriously impressive. Imagine you own 50% of the company: what would need to be true for the company to make it big?

You are employed by the business, in the service of the business, even though you will spend most of your time with the development team and your end users. When people say, “We need to prioritize the most important thing,” that thing is not always the end user.

This is harsh, but in my experience, true. You will sometimes have to defend the end user in front of the company, and there are some things you can’t always win.

The products that are best received are the ones that do well for the company and do well for the end user. Sometimes you will have to figure out how to do good for the company without hurting the end user. The more senior you get, the more these trade-offs will become frequent in your discussions.

Not everyone in your team will have an “all-in” mentality.

If you work in a startup and most of your colleagues are under 30, you might hang around in the office just for fun. Back when I was working in-person, I would hang around with people until 8-9 pm. It often felt like university part 2.

When you join a bigger company, you will find yourself surrounded by people at different phases in their life. Life happens, people have kids, and the company is a way to earn a living. That’s fine: don’t force it.

Sometimes it’s just little things that make the difference. That person will appreciate that you put meetings on Thursday only after lunch so they can be there for school runs.

If you pivot from fields where work was quantifiable. This will be a shock.

I came from design; I had a portfolio that I could point at and just say, “I did this.”

There will be times when you will be tired at the end of the day, and you won’t even know what you got done. If your product cycle is long, it will take a while to understand if you did a good job.

This is not to put the job on a pedestal and say that it’s a thankless job. But in the end, you are an enabler for the team and the business. Some people will clap for you when a product does well. Take it in for a moment, then immediately point towards your team: the people that did the work.

It’s great for them to get the recognition they deserve; you already had your reputation strengthened.

You won’t take those claps with you in your next job, but you will be there with your team tomorrow solving the next thing.

Not all companies are the same

At the beginning of this essay, I argued that you get better by getting more reps in. But not all reps are equal: some are worth 10x more than others.

If you join a slow-moving company, you might get one or two meaningful reps per year. But if you join a fast-moving company, you might get a big multiple of that. The best place to learn is a funded startup with real momentum. Not just because of the velocity, but because their existence requires them to make bigger bets.

They often won’t have the luxury of over-analysing every decision. You will have to make calls with incomplete information and figure things out as you go. It’s going to be a little bit more stressful, but you will optimise your rate of learning.

Some venture funds have job boards for their portfolio companies. Here’s some from a16z and Sequoia

A disclaimer here that, sometimes when things move fast, they are driven by chaos. Fast-moving companies are great for learning through repetitions, but not always the best places for mentorship or structure.

Some of this won’t apply to you. Either you had a different experience, or you do not naturally function like this. As always, exercise caution, challenge my assumptions, and take whatever is needed.

I am sure in a couple of years I will have more things to add, but I hope something in here was useful. I appreciate you reading this.

Subscribe now

A common shortcut is using pre-built component libraries like Google's Material UI. They give you the building blocks, but they don’t think about the whole user flow for you. You still have to figure out how everything fits together.

But a lot of the time, we weren’t doing novel things. If you look closely at most software products, you'll notice a lot of overlap in user flows. There's usually little reason to reinvent simple things like account creation or password resets.

If your time should go toward what makes your product unique, how do you define a good user experience as quickly as possible?

Blank pages are a trap

Do not stare at a blank canvas wondering "Hm, ok how should the email field look like?”

Multi-million dollar companies with bigger teams have thought long about this, and you can piggyback off that and get to a great experience faster.

Avoid looking at:

• Design award websites: They showcase originality, not proven usability.

• Dribbble: Prioritizes aesthetics over function.

Instead, look at:

• Competitor sites: Make accounts, take screenshots.

• Aggregators like PageFlows or Mobbin for quick reference.

Common patterns: like password strength indicators, usually exist for good reasons.

Take notes on:

• Common UI elements like email, password fields, confirmation flows

• Visual and layout conventions (centered forms, responsive design, clear buttons, logos at the top)

Think of a Venn diagram. If every product in your space does something the same way, there’s probably a good reason. If one company does something different, ask yourself: Is this intentional, or just a mistake?

Sometimes friction is deliberate. Some companies require credit card details upfront: not because they have to, but because they only want serious users. It’s not a fast experience, but that’s the point.

If what you’re building isn’t straightforward, look outside your industry. Say you’re designing a feature that collects medical data for prescription renewals.

If you can’t find direct comparisons, zoom out: Who else collects sensitive data? Mortgage lenders, tax services, they all deal with high-stakes information. Look at how they build trust, explain risks, and guide users through complex flows.

Be Explicit About Your Goal

If you're designing a sign-up page, the goal isn’t just "two text fields and a sign-up button." It’s something real, like: "Make signing up as effortless as possible."

Now, turn it into a question: "How can we make signing up as easy and obvious as possible?"

Some answers:

• Show password strength before users hit submit.

• Give them a reason to sign up, not just a form to fill out.

This also raises new questions:

• Should users log in right away, or confirm their email first?

• Should they land on a confirmation page, or just get a subtle success message?

You won’t have every answer upfront, but asking the right questions keeps you focused on what matters.

Think About Edge Cases

Real users don’t behave how you hope. They rush, skip instructions, and get distracted.

Always ask: What could go wrong?

• Take it field by field: what happens if a user rushes through and makes a mistake?

• Then zoom out: what happens across the entire flow?

If you can make the experience smooth for someone impatient and distracted, your other users won’t have any problems.

Bad UX isn’t always about ugly design: it’s often just a confused user who doesn’t know what went wrong or how to fix it.

For example:

• What if they don’t pay attention when creating a password? They’ll set a bad one, then get locked out later.

  • Fix: Add a "confirm password" field to force them to retype it.

• What if passwords don’t match? They’ll hit “Sign Up” and get an error. That’s frustrating.

  • Fix: Show a mismatch warning as soon as they type the second password.

Use AI to spot blind spots

Tools like ChatGPT can highlight UX issues you might miss. It’s a quick sanity check: not perfect, but better than guessing.

Tools like ChatGPT can highlight UX issues you might miss. It’s not perfect, but it’s better than guessing. Some prompts to try:

• Red Team vs. Blue Team: “Critique this sign-up flow: where could users get stuck?” vs. “Defend this design: what makes it intuitive?”

• Industry Standards: “How do top SaaS companies design their sign-up flows?”

• Edge Cases: “What happens if a user mistypes their email but doesn’t notice?”

Other tips:

• Decide what you're going to measure. "Good UX" might mean conversion rate, user-retention or user satisfaction. Design will always be subjective to a degree. The less subjective you can make it, the better your sanity will be at the end of this.

• Keep your colours simple. One primary, one secondary and one accent colour. Coolors is a great little tool for this.

• Keep the language familiar to the users, not to the people building it. Don't say "database error" say "We couldn't save your changes."

Closing Thoughts

Startups need to move fast and perfectionism, especially around aesthetics, is often unnecessary.

If you're not a designer, but you need to get things over the line, focus on usability, not novelty. A clean, obvious user flow beats an original, but confusing one every time.

Sometimes you will need novelty, but ask yourself clearly: "Where do we actually need to differentiate?"

Doing what others are doing isn’t just copying: it’s using other companies to train your users for you. When you follow established patterns, users already know what to do, and you don’t have to teach them from scratch.

Innovate on your core value; for everything else, stick to what works.