👋 Welcome to today’s edition of Build & Lead (formerly the CTO Blueprint), a newsletter by Appolica. Every month, we dive deep into the tech, product, and leadership challenges that keep founders and agencies up at night.
There’s a version of this post where I tell you AI saved me hours every week and helped me take on 5x more work than before. It did. But in the process I discovered that “faster” and “easier” were never really the point.
What actually happened is I stopped being an operator. And my job became more interesting as a result.
At Appolica, PMs are team leads. Each of us has a dedicated team of developers. When we close a client, we own that relationship end to end. We’re responsible for our team’s business margins. We run one-on-ones. We lead performance reviews and salary conversations.
In many ways, it’s like running a small company inside the company.
That means the job is always split between three things: enabling the team to deliver, doing the product work, and thinking about the business. Dividing attention between all three is exactly what kills your ability to do any of them well.
The context system I’m about to describe is what helped me stop dividing my attention, focus on what I actually value in my role, and grow as a professional.
When AI came into the picture, I did what most people do. I started using it for everything. The output came fast. Then I spent most of my time correcting it.
The issue wasn’t the AI. The issue was that every time I opened a new session, I was starting from zero. I had to re-explain who I am, what the project is, what I care about, what I’ve already decided, and why. If I skipped any of that context, the output was generic. Usable, maybe. Mine, no.
I looked at it from a PM perspective: the process wasn’t making me more efficient. The back-and-forth of correcting and adjusting left no room for actual thinking. I was so focused on getting the model to say the right thing that I stopped generating fresh ideas myself.
The fix wasn’t better prompts. It was removing the need for prompts altogether.
The idea is simple: if Claude already knows who I am, how I think, and what I’m working on, I don’t need to explain myself every session. I can type a few words and it knows what to do.
Project folders inside the app weren’t cutting it. So I built a context layer that lives on my computer. A folder called Claude-Context with several subfolders, each containing markdown files I keep under 50 lines - short enough that Claude reads them fully without summarizing or skipping details.
The files were written by Claude itself, so the syntax is optimized for an AI to read, not a human. I pointed Claude Cowork to always read through these files before executing anything. And the way I fed it my decision-making process was by making it interview me extensively. Not about tasks. About how I think.
If you’ve heard of the Second Brain concept, this setup was inspired by it. A lighter version that doesn’t burn unnecessary tokens, but good enough for the job.
Here’s the basic structure:
About Me folder. This is where Claude understands my role, my day-to-day responsibilities, and what my job actually looks like in practice. Not a job description, the real version. What I own, what the pressures are, how my team is structured, what I’m accountable for. The non-traditional Appolica setup needs to be in here too, because without it, Claude defaults to a generic idea of what a PM is.
Beliefs folder. This one took the most time, and it’s the most valuable. I had Claude run a long interview with me about how I think. Controversial opinions I hold. What makes me cringe and why. Where I draw inspiration. How I prefer to lead. What I believe about team dynamics, flat structures, people management. Friendship and loyalty. My decision-making process in different situations. Books I read. Things I follow. The goal was to capture everything that’s obvious to me but invisible to anyone I work with, including an AI. Once this existed, the outputs stopped sounding generic. They started sounding like me.
A folder per project. For each project I’m running, I created a separate folder with everything that matters: the brief, the user research, past decisions and the reasons behind them, my vision for the product, my concerns, the blockers, the next steps I’m planning and why. I also ran a version of the beliefs interview tailored for each project specifically. Where I see it going, what I’m optimizing for, what I’m worried about, context on the stakeholders. Anything useful, I dumped in the markdown files.
Writing guidelines folder. This one matters more than people expect. It contains my writing style, my mechanics, and a list of anti-AI patterns. Phrases and structures I actively avoid because they make writing sound generated rather than thought through. Any time I ask Claude to write something for me, this folder is what makes the output sound like it came from a person.
The update loop. A system only works if it stays current. This is the PM in me, documentation dies when it’s not maintained. So I created a skill that handles updates. When we take a meaningful step (a decision, a discovery, a shift in strategy) I tell Claude to refer to that skill and update the relevant documentation. It doesn’t need to be perfect. It just needs to be current.
The result: I open Claude Cowork, it reads through the Claude-Context folder, and we move. A few words is all it takes. No re-explaining context. No long prompts. No correcting tone. The operational layer runs without me.
That time went somewhere else. Here’s what I found there.
The shift wasn’t more hours. It was cleaner headspace.
As more of the operational layer got handled, I started spending much more time on the business side. Finding the next right move. Exploring channels. Having strategic conversations. Thinking in longer time horizons. The split between delivery and strategy started to close, not because delivery got easier, but because I stopped spending my best hours on things that didn’t need my best hours.
I also reached a different kind of team dynamic. I now have an overview of the delivery process without being inside every decision. The team moves with enough autonomy that I can step back. And that freed me to do what I actually believe a PM should be doing: thinking ahead, communicating direction, and creating space for the team to challenge me.
More clarity means you finally see the real problems. A few things surfaced once I had room to think.
Speed creates a vacuum. Engineers build faster now. The backlog runs dry faster than expected. And then the team turns to you, waiting for the next thing. The challenge is that some decisions need time. Some things have to hit real users before you know what the right next step is. The feedback loop hasn’t gotten faster just because the build cycle has. What I do: I name it. I tell the team we’re in a validation moment, not a build moment. We need to learn before we can decide. That reframe takes the pressure off, and it’s almost always true.
Everyone has an opinion, and that’s mostly good. As AI took over the routine work, team members started engaging with the product. That’s something PMs have been asking for for years. But it creates noise. Everyone’s opinion comes with a bias, and most people don’t realize their bias doesn’t represent everybody. When someone brings an opinion to me, I ask questions. I bring real use cases to test that opinion against actual user behavior. And if someone can name a specific experiment that would prove or disprove their idea, I let them own it. They’ll either be right (great for the product) or they’ll learn something. Either way, worth exploring.
AI utilization varies enormously by person, and that’s a performance topic now. Some people lean in so hard they’ve stopped thinking. They paste a prompt, accept the output, move on. The work looks fine on the surface but lacks the judgment an expert is actually needed for. Others barely use AI at all. Both extremes cost you. The conversation I now have with people: who needs to own the end result here? If they can’t name a teammate, they’ve missed something. Then I ask: are you prompting and correcting, or are you bringing your own expertise to the model so it can actually make you more efficient? That shift in framing changes the conversation.
Clients are not all on the same page. Some love the speed. Others read a short timeline as underestimation. The most effective thing I’ve found: show them, don’t tell them. I share specific products we’ve already built that are gaining real market share, the timeframe we built them in, and what that speed enabled the founders to do. Then I get into the tech, because any client that can find similarities to their own product starts to see what’s actually possible.
You don’t need to build the whole system on day one. Here’s where to start.
Write your real About Me. What you own, what you’re accountable for, how your team works, what the pressures look like day to day. One markdown file. Be specific. Generic descriptions produce generic outputs.
Do the beliefs interview. Open Claude and ask it to interview you about how you think. How you make decisions. What you believe about team dynamics and leadership. Ask it to dig deep. This takes a few hours but it’s the most valuable thing you’ll do. The output stops being generic the moment Claude understands your reasoning, not just your instructions. Keep each markdown file to around 50 lines. This helps Claude read each file fully without skipping details.
Create a folder for your current project. Keep things separate. One file for the project brief, another for target personas, one for features and their use cases, another for GTM and campaigns. Treat each as a live document, not an archive. The more honest you are about what you’re uncertain about, the more useful it becomes.
Create an update skill. After any meaningful decision or shift in direction, refer to the update skill so your documentation stays current. This one matters most. Skip it and you go back to prompting.
Start with one task you hate. Pick the most repetitive thing you do every week. Writing emails was a big one for me. Run it through the system once it’s set up. That first result, the one that actually sounds like you wrote it, is when it clicks.
The full system takes a couple of days to build properly. It’s not a shortcut. It’s a different way of working - one that transforms the process instead of adding another layer on top.
The hardest part of the job stays the same. It’s the why.
Why are we building this? Why does it matter? Why should the team give it their best work, especially on the days when everything feels uncertain?
AI can help with almost every other part of the job. But it can’t give your product a purpose. It can’t answer the question of why this work matters in a way that actually lands with the people building it.
That’s still yours. And in a world where so much is becoming automated, that ability is becoming more valuable, not less. So take the chance to automate what you can, and free up time to become a sharper version of yourself.
Keep coming back to it. Make it simple.
I stopped being an operator. My job is more interesting now. Not easier. More interesting.
The tools didn’t do that. Building the right context for the tools did. The difference between using AI and using it well is the difference between operating a machine and working with one.
If you’re a PM still spending your best hours prompting and correcting, try the other side. Set up the context once, properly. Then see what you have time to think about.
It’s worth it.
Got feedback or just want to get in touch? Reply to this email and we’ll get back to you.
Want to see more of us? Have a look at our LinkedIn account. Interested in what we do? Visit appolica.com.
Thanks for reading & until next time.
Best,
Christina & the Appolica team
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.