That speed helps until you bring someone in. In my last post, I explained why first PMs often struggle. The main reason is they can’t access what’s in your head. They see your decisions without the years of reasoning behind them, so they seem to miss the point. The knowledge that helps you move quickly is out of their reach.

You could let your first PM start from scratch and create their own vision. But if you do, you might end up with two different directions. Early companies need everyone working from the same context to stay aligned.

Writing things down has always been the simple solution, but founders skip it because it feels faster not to. What’s different now is the benefit. Before, new hires might read your notes once and never look again. Now, AI can find, understand, and use that information whenever the team needs it.

What a shared brain looks like

You might have heard of the second brain, a way to store what you know outside your head. Tiago Forte created a method for this, and Lenny Rachitsky has written about PMs using tools like ChatGPT and Claude for their own second brains. Those are personal. As a founder, you need a shared version that your first PM can use, your team can add to, and your AI tools can access.

Engineering teams already know what this looks like. It has three layers.

The first layer is the front door: a single file at the root of your repository called AGENTS.md. Major labs and tool makers use this as a standard, and it’s already in tens of thousands of repositories. It’s like a README for agents. It explains what you’re building, who it’s for, which decisions are final, and how you want things to work.

Behind that file is the store, where most of the context is kept:

• the current plan, and the success criteria you’re judging it against

• a running decision log, each call recorded with the reasoning behind it

• customer signal: conversation notes, research, and the feedback that drove real decisions

• the dependencies you’re waiting on, and the questions still open

• recordings and transcripts of your meetings, which most software now captures automatically

The last layer consists of systems that change too quickly to document: your analytics, your error logs, your issue tracker, and wherever the team talks. Using MCP, a standard that lets agents pull data from other tools, you connect them once, and the agent can reach them whenever needed.

How I built one at GitHub

As a senior PM at GitHub, I built this exact setup, though I didn’t have a name for it at the time. Our team used seven main parts:

• a fresh GitHub repository for each major initiative, holding the plans and context as markdown files

• Copilot CLI as the agentic harness, GitHub’s answer to Claude Code

• Issues for intent and work tracking

• Discussions for exploring pitches and early ideas

• Pull requests as the alignment layer over those docs and plans

• MCP tools wiring in our analytics and Slack

• Agentic Workflows for the recurring chores, like the weekly updates and issue triage

Once everything was set up, I stopped writing things by hand. I didn’t write memos, product updates, issues, PRDs, or epics myself. Instead, I told Copilot CLI what needed to be done, provided the context, and then reviewed the results carefully to ensure I agreed with every word.

I mostly worked from the terminal, with several sessions open at once. Later, I switched to the GitHub Copilot app when it made it easier to keep sessions separate. I spent most days in those repositories, and so did the AI.

I chose a git repository instead of a doc or wiki for two reasons: the AI could work directly inside it, reading and editing files, and the version history automatically tracked what changed and why.

When I wanted feedback on a plan or document, I opened a pull request, gathered the team’s comments, and made changes using Copilot CLI before merging the final version. This let us stay aligned without meetings, working together even when we weren’t online at the same time.

How to start building yours

Almost every part of my setup was a GitHub product. We dogfooded everything, so those were the tools to hand. You don’t have to copy it exactly, and the same setup works with alternatives.

Choose the part of the product your first PM will manage, or the whole company if they’re your first hire, and set up a repository your AI tools can read. Start with the front door: one file that explains what you’re building, who it’s for, and what’s already decided. Then add three things to the store: your current plan, the decisions that led you here and why, and anything you’re still unsure about. It doesn’t need to be perfect or finished on day one.

Keep it up to date. Whenever you make a new decision or change your thinking, update the repository. This takes some weekly discipline. Before you ask your AI for help, point it at the repository so that “work from what’s already here” becomes the default.

To build a real product function, you have to give up the thing that made you fast: keeping everything in your head. Founders who succeed at handing things over start sharing their thinking early, before and after the PM joins. When you do this, your first PM and your AI tools can start from what you already know.

I help founders build their product function from the ground up through coaching and advisory. Getting what’s in your head into a shared brain is where a lot of that starts. If you’re facing this handover, or looking for help building your product org, get in touch.

What’s the most important context you’re still keeping in your head? Reply and let me know.

I’ve been a lot of different kinds of PM: a first PM, a founder acting as PM, a product director, and most recently a PM at GitHub. Of all of them, the hardest to get right is a startup’s first-ever PM. That’s why I’m restarting this newsletter with a tighter focus: the initial phases of building a product org, starting with the first PM hire.

Here’s what that looks like. The search is over, the offer has been accepted, and someone finally owns product. The founder expects to recover time, the PM expects to take responsibility, and everyone is optimistic. Then the handover proves harder than expected. This usually isn’t a sign that the wrong person was hired. It’s a sign that the company hasn’t yet changed how product leadership works, because hiring a PM doesn’t automatically transfer the founder’s context, judgement, or authority.

Why the first PM struggles

When a first PM stalls, it is tempting to question the hire. In my experience the cause is almost always one of three things, and all three sit with the founder rather than the PM.

• Context never gets transferred. Years of customer conversations, failed experiments, and hard-won judgement live in the founder’s head. The PM sees the decisions but not the history behind them, so they cannot reproduce the founder’s thinking and keep looking like they do not understand what matters.

• Decision rights are left implicit. “Own product” is said but never defined, so the PM is accountable for outcomes without the authority to match and is never sure when they are actually allowed to disagree with the founder.

• They get conclusions and silence. Founders save time by handing over answers rather than the evidence and reasoning behind them, so the PM never builds independent judgement. Feedback then arrives late, long after the moment when it would have helped.

The rest of this piece is about closing these three gaps, along with a few related traps that make them worse.

1. Your role changes before theirs can

Before the first PM arrives, product management happens inside the founder’s head. Customer conversations, sales objections, technical constraints, investor expectations, failed experiments, and strategic choices accumulate over years. The founder can make a decision in minutes because they’re drawing on context that nobody else can see. The new PM sees the decision, but not always the history behind it.

That work is both tactical and strategic at once: reviewing feature decisions, sitting in sprint planning, checking the same analytics weekly, on top of fundraising, hiring, and everything else running the company demands. Hiring a PM should lift the tactical layer off the founder’s plate, freeing them for the parts of the company only they can do. Most founders keep reaching for those tactical decisions anyway, because they’ve been close to the product for so long that letting go feels unnatural. Distrust has little to do with it. That habit does more to keep a founder in the PM’s way than any lack of trust does.

Your first PM needs more than a roadmap and a list of introductions. They need access to the thinking that produced the roadmap, and they need to understand which assumptions are firm, which are open to challenge, and which decisions they can make without asking you. The goal is to build, over time, a system through which context and responsibility can move.

2. Start with outcomes before the backlog

It’s tempting to give a new PM the backlog because it’s concrete. There are features to prioritise, customer requests to resolve, and bugs to fix. But a backlog tells them what people have asked for. It doesn’t tell them what the company is trying to change.

Start with a small number of outcomes instead:

• What must become true for customers?

• What must become true for the business?

• What would meaningful progress look like in 90 days?

• Which assumptions need to be tested first?

This gives the PM room to develop a view rather than merely administer inherited work. A useful test is whether the PM can explain the company’s priorities without referring to a list of features. If they can’t, the gap is usually strategic context, and a better roadmap template won’t close it.

3. Work through the PM, not around them

Founders who struggle to let go often show it by giving direction straight to engineers or designers, or quietly doing parts of the PM’s job themselves. The team notices. If the founder keeps routing around the PM, the obvious read is that the PM’s judgement isn’t trusted, so why should anyone else defer to it? Route requests and direction through the PM instead, even when it would be faster to just tell the engineer yourself.

4. Make decision rights explicit

“Own product” sounds clear until a real disagreement appears. If the boundaries stay implicit, both sides tend to make the safest possible assumption: the PM asks for approval too often, or makes a call they believe is theirs only to have it reversed without warning. Write down the initial decision rights, even if they’ll evolve, and watch for the quieter version of the same problem: a founder who wins every argument by default, simply because they have more context and authority, teaches the PM to stop pushing and loses the second opinion they hired them for. I’ll go deeper on this, with a decision-rights map template, in a future edition.

5. Don’t split strategy from execution

Founders also fall into a related trap: dividing the work cleanly in two, with the founder doing the strategy and the PM executing it. It’s tempting, and it isn’t entirely wrong, but treating it as a hard line turns the PM into a delivery function and wastes most of what you hired them for. Better to split by scope than by activity: give the PM a real end-to-end slice of the product, a major feature area, for example, where they own both the strategy and the execution, and expand what they own as they prove themselves. I’ll dig into how much strategy a first PM should actually own in a future edition.

6. Share the evidence behind your conclusions

Founders try to save time by giving the PM the answer. “We need this feature for enterprise.” The conclusion may be right, but if you share only the answer, the PM can’t learn how you reached it or develop the judgement to make similar decisions independently.

Share the underlying evidence when you can. Invite them to customer and sales calls. Forward the difficult support conversations in full, so they see more than a tidy summary. Explain which experiments failed and why. Show them where your confidence is high and where you’re guessing, and talk through an important decision before announcing the answer. This may feel slower at first, but it’s how the PM becomes faster later.

7. Give feedback while it’s still useful

Many founders delay feedback because they’re busy, uncertain, or trying to give the PM space. The PM experiences the silence differently. They may assume they’re doing well, or sense dissatisfaction without understanding its cause. By the time the founder raises a concern, weeks of avoidable frustration have piled up.

Early feedback should be frequent, specific, and tied to real work. Instead of saying, “Be more strategic”, discuss the recommendation they just made. Which part was strong? Which context was missing? Where did their judgement differ from yours? Was the problem in the decision, the reasoning, or the communication, and what should they try differently next time? Do the same when the work is good. If the PM only hears from you when something is wrong, they can’t tell which behaviours to repeat.

8. The first PM shouldn’t have to grow alone

It’s just as easy to fall into a different trap here: leaving the first PM to grow alone. In an established product organisation, a PM has experienced product leaders around them to review a strategy or help interpret difficult stakeholder feedback. The first PM at a startup often has none of that, and the founder rarely has the time or product background to fill the gap alone. Founders should decide deliberately where that support will come from, whether that’s an advisor, a peer, or a coach. I’ll go deeper on this in a future edition.

The whole handover works the same way. A first PM gives a founder more leverage, but only if the founder does their part: sharing context, clarifying authority, and giving the PM room to grow into the role. The founder’s product job doesn’t disappear when the PM arrives. It changes from personally carrying every decision to creating the conditions in which someone else can carry more of them well.

I’m currently open to coaching a small number of first PMs at seed to Series A startups that have recently made the hire, working as an independent, confidential sounding board.

If you’ve hired your first PM, what’s been hardest about helping them succeed? Reply and tell me. I’d like to use what you’re wrestling with to shape future editions.

Managing a team of software developers can be hard. The success of your business depends on developers’ output, but it can be difficult to understand the technical pressures they are under and how well they are performing. You want to get the best out of your team but are unsure how to do it. Some people try to solve this by digging into technical details and taking a hands-on approach. Others prefer to set the product specifications, let the developers manage their own work, and hope for the best. There are risks to both of these approaches that could mean you are blind-sided by poor implementation of your product vision. Let's take a look at why approaches at either end of the spectrum might fail and how you can find a "Goldilocks approach" that works just right.

When you want to dig in

When working with a team of developers, it is very tempting to try to understand all the technical details of what they are working on. You assume that the more you know, the better! You can help your team make decisions! You feel you are in control!

But is this involvement helping or hindering your team? Are they spending their time working on software problems, or are they spending it explaining details to you?

There are a few risks here:

• You lose sight of the "big picture"” getting lost in the details

• You start making technical decisions for the team with incomplete or incorrect understanding. Your team might be "dumbing down" for you, but you don't realise it.

• You focus too much on technical performance for its own sake

• Offhand comments about your preference for a particular technology choice or approach might seem like concrete decisions to your team, particularly if you are "the boss."

• You will undermine expertise, potentially damaging morale

To avoid falling into these traps, there are two questions you can ask of your management process: 1) what benefits is this producing for the end-user of the product, and 2) does this help us build in response to change faster and more accurately? This is because without user insight, there is no point in what you are building, and without a process to build, you will be unable to respond to changes, including an improved understanding of what your users want. After you speak with developers, figure out how much time you spent talking in the context of these two questions and how much time was in the nitty-gritty details of the code.

The code should serve the company. The company should not serve the code.

You should ensure that technical decisions are documented with reasoning and that items added to the backlog are well-detailed. It can be as simple as: "We are building this to help the users do X" or "We are changing this to make our build process faster." You should prioritise with input from the development team. If you can't explain the reasoning, you shouldn't be making the decision. Set the terms, and let the experts decide.

When you go hands-off

If you don't have a technical background, it's easy to be overwhelmed with detail. Software developers are speaking a foreign language. Many people go hands-off, presenting product specifications and insisting, "Just build this," usually paired with "and tell me exactly how long it will take you." You might even tell yourself that you are empowering your team to just get on with it.

The risk of this approach is:

• You might not understand technical limitations that may come back to bite you. For example, the software might be slow due to a particular technology choice. Speed wasn't added to the specification; it's only when you realise it's too slow that it becomes an issue.

• You don't understand the "size" of the changes you are requesting, how complicated they are, and how they might impact delivery timelines.

• You might miss where the developers have a different understanding of how the product or business process should work than what you have.

So how to avoid this?  

Firstly, learn the basics. Understand the "parts" of the system, but don't get bogged down in the detail of how each bit works.

Second, focus on the user perspective, not just on how things look, but on how things work. This should include performance criteria like speed, accessibility, and what the most-used parts of the software might be.

Third, understand how your team is modelling the real-life problem you are trying to solve, and ensure that the model is consistent with your vision and understanding of how things work. You should create a shared framework of understanding, the naming of parts of the system with your team, and how data flows between processes.

Without a shared understanding of the software model and how that corresponds to reality, you will end up working at odds with your team and likely also with your customer.

In Conclusion

Effectively managing a team of software developers can be a daunting task. Striking the right balance between a hands-on and hands-off approach is difficult. Get the balance wrong, and your development efforts will become unsustainable.

The "Goldilocks approach" recognises the risks at each end of the spectrum and tries to mitigate them. This approach involves understanding the technologies in play without being consumed by their intricacies. By focusing on the user's perspective and understanding how your team is modelling the problem, you can maintain a meaningful dialogue with the team, with the customer, and with the reality of the problems you are trying to solve. Creating a shared language around the system's components facilitates better communication and mutual understanding.

Are we building to solve a problem, or are we building for the sake of building? Ultimately, only a balanced team gives the right answer to the question.

Many of the things you can outsource or delegate. These tend to be general business activities, like accounting, bookkeeping, or drafting legal documents, and are not what makes your business unique (a.k.a. your “secret sauce”).

But there are some activities that founders should never outsource or delegate until they can nail them first. One of them is sales.

For me, that was a problem when starting Prodsight. I’m an introvert, and speaking to strangers is an uphill battle I have been fighting for as long as I can remember.

Building up the motivation to sell

Going through school and university might be possible without overcoming the fear of selling. Heck, you might even manage most jobs. But I don’t think you can succeed as a founder without getting comfortable with selling.

It might be tempting to think that if your product is self-service and you are pursuing a Product-led Growth (PLG) model, you don’t need to learn to sell. Users will sign up, input their credit card details, and voila!

But even if you can make that work, that’s only half of the puzzle with product sales. You also need to think about selling your company. Whether selling to potential investors, employees, co-founders, partners, media or being on a podcast - that’s all part of the same skillset.

Being able to sell your product and your company is essential.

As a founder, I was my startup's ambassador, and I realised that unless I got over the hump, I wouldn’t be able to move my company forward.

Once I made that realisation, the motivation was clear. I needed to learn to sell. I needed to get good at it.

Overcoming the fear of selling

The fear of selling my product and my company came down to my lack of confidence. I was not confident that our product was strong enough when pitching potential customers. I was not confident that my background was impressive enough when pitching investors. I was not confident in my ability to handle a conversation in which the objective was to have the other party buy something from me. And the biggest of all, I was scared of rejection.

So how did I build up the confidence to sell despite self-doubt? How did I grow a thick skin to be immune to rejections?

The reality is that I didn’t—at least not all the way. I just got good enough to be effective. Good enough to close early customers, raise investment, and eventually even sell the company. I think of salesmanship as a lifelong skill that can be visualised on a spectrum. I moved from the “Absolutely paralysed” stage to the “Selling stuff” stage.

Focusing on the problem instead of the solution

In my head, sales were Shelley Levene from Glengarry Glen Ross (1992) desperately trying to sell stuff people don’t want… and failing.

In my first few sales demo calls, I would immediately jump into sharing my screen and describing every feature of our product. I would do 90% of the talking and walk away with no idea of what the prospect thought of the product, let alone whether or not they even had the problem we were solving.

It wasn’t working, and it was everything I feared sales would be like.

Then, after some deep reflection, I shifted my approach. Instead of doing a hard sell, I would focus on the customer’s problem instead.

I started every sales conversation by understanding the customer. What is their business? What is their role, and what does a day-to-day look like? What challenges are they facing on a day-to-day basis? I became a researcher. The prospect was doing most of the talking.

I would talk about our solution only when and if I genuinely understood whether we could solve this customer’s problem.

I started actually enjoying these conversations. I even reached the point where I looked forward to making sales calls.

Every customer conversation became a learning opportunity. It was no longer about just winning the sale or dodging a rejection. It was about advancing my understanding of the market, customer profiles, alternative solutions, and sales objections - all of which I would analyse and feed right back into our strategy.

And it had an impact on the conversion rates as well. Prospects became more comfortable speaking with me. They were no longer on defence, trying to dodge my sales tactics. We were having a genuine conversation to see if we could help each other. And if not, we would part ways amicably without any hurt feelings, having still benefited from talking to each other.

Growing confidence through practice

Confidence is not something you are either born with or not. It’s something that you can grow over time. It’s also something that you can lose and might need to rebuild.

As I practised selling, I naturally got better over time. As I closed deals, I gained confidence in our product's value and my ability to connect customers’ needs to our solution and get it over the line.

With each conversation, I would better predict customer questions and develop better answers to common objections. I built up a bank of customer stories that I could quickly recall and use in the conversations, helping me to build trust.

As I became more fluent in sales, I naturally came across as more confident, which impacted the prospects. People are good at picking up on various cues, and if you come across them confidently, they are more willing to trust you and buy from you.

Closing thoughts

Overcoming the fear of selling was one of the hardest things I had to do as part of my founder’s journey. But it wasn’t just a gruelling task I had to endure only to reach the destination. It became a lifelong skill that I will use for years in my work and personal life.

If you are a founder struggling with the fear of sales, I highly encourage you to attack it head-on. You will be a better founder once you get over the hump.

When I quit my job to start Prodsight, that became an instant reality for me. I no longer had a boss or colleagues to report to; I could decide when I worked, and there certainly wasn’t anyone telling me what I should or shouldn’t do.

Except it didn’t feel as good as I expected. Certainly not as “freeing” as I imagined going in.

Instead, I was met with a crippling sensation of anxiety, guilt, and fear. I was anxious about not doing the “right” things or not fast enough to advance my startup. When I got stuck in an unproductive state, I would feel guilty for wasting the time and the opportunity in front of me. And on the gloomiest days, I would fear that the whole thing would fail, burn through my savings, and leave me with nothing to show for it.

I was so focused on the financial part of surviving the startup journey that I forgot to figure out an even more important aspect, my psychology.

I craved structure

I realised that I got used to the structure of having a set workplace to go to, set hours, a group of people to interact with every day, and a source of direction from my manager.

As I’d kiss my wife goodbye as she went to work, I’d have the entire day to work on my new startup. But there was no place to go to, no set hours, or anyone to interact with. I was entirely on my own.

I was craving the structure my job provided and had taken for granted.

Rebuilding some form of sanity meant re-establishing the environment that made me productive as an employee:

• Workspace

• Work hours

• Accountability

Workspace

After the COVID-19 pandemic forced us all to become remote-working experts, it is now my most productive and preferred work mode. However, when I started Prodsight in 2017, five days in the office was the de facto way of working and something I was used to. So when I no longer had an office to go to or anyone to talk to all day (I was a solo founder), staying home to work on my startup felt incredibly isolating.

The natural temptation to procrastinate was unbearable. Instead of trying to work on the “hard” things of validating my business idea, building prototypes, or making plans, all I could think of was making another sandwich, another coffee, or watching just one more episode of my favourite Netflix show. All of that is with a side of guilt and self-loathing.

I just had to get out of the house!

Since I was bootstrapping, I opted for the cheapest option of working from a nearby coffee shop. Getting out of my flat gave me bursts of productivity that I needed to make progress. The psychology was that since I had gone through the effort of leaving home and the expense of buying a coffee (a luxury at the time), I now must do something productive to make it all worthwhile. It worked. I worked.

Eventually, my back started hurting from days of sitting on hard coffee shop benches hunched over my laptop, and I decided to get a co-working pass at a nearby co-working space.

Work hours

Technically, I could work on my startup whenever I wanted. There was no one to tell me when I should be working.

However, it made sense for me to set regular working hours for my sanity. I decided to align my hours to my wife’s, which meant a standard Monday to Friday, 9 am to 5 pm.

Working this corporate schedule meant a return to a routine, giving me some sense of normality in the chaos of the early days of a startup. I would try to make as much progress as possible during the workday, knowing that I would l have to “clock out” at the end of the day. This put a rigid boundary on how I viewed my workload and minimised procrastination. I could no longer push the work into the evening or weekend, at least in theory. In practice, I sometimes worked late evenings and weekends to get things done.

The other benefit was that I could spend time with my wife once she returned from work without feeling guilty about not having done enough.

Accountability

Even in jobs where you have a lot of freedom, there is always someone you are accountable to. Whether it’s your boss, your colleagues, customers, or partners, there is always a motivation to deliver or else.

In the early days of a startup, there is none of that! You are your own boss, you haven’t hired any employees, and you don’t yet have any customers or partners because you don’t have anything to sell.

We are conditioned to do things for others, whether consciously or subconsciously. Initially, I found it very difficult to hold myself accountable. I needed someone to validate what I was doing. I wanted someone to keep me accountable.

For most startups, I suspect this would be solved by having a co-founder, but I was flying solo.

I contacted my good friend and startup founder Martin Lind and asked him to be my accountability partner. We would meet in a cafe every two weeks, and I would have to report to him on the progress I had made on my startup, the challenges I had encountered, and the next steps I wanted to commit to.

The knowledge of the looming meeting with Martin meant I always had the incentive to make progress on my startup and complete the action points so I would have something meaningful to share with him. I knew deep down that if I failed to keep up, I would lose his trust, and our “arrangement” would fall apart.

He was incredibly patient and generous with his time and feedback. I am forever grateful for that. Martin’s input was so valuable that I asked him to join our board of directors and gave him stock options.

Once I hired employees, raised investment, and secured early customers, I no longer needed to fabricate accountability. The startup suddenly felt very real, and I felt an immense sense of accountability to the people I pulled into the journey for me. The big challenge was getting to that point.

Closing thoughts

Surviving as a startup is as much a psychological puzzle for founders as it is about skills, knowledge, or finance. I surprised myself by craving things I seemed to be running away from, like a fixed workspace, consistent work hours, and external accountability.

It might be different things for different founders, but staying productive in the early days is critical as you are the only engine keeping things going. The day you stop, the whole thing falls apart.

I've observed that first-time founders often view startups as having two main disciplines: business and technology. They believe that having someone skilled in sales and marketing to sell the product, and someone proficient in technology to build it, is sufficient. This perception is not entirely incorrect, as these two disciplines are crucial for building a technology startup. 

However, when founding a startup, it's not as simple as taking two professionals who excel in engineering and business and having them continue their respective roles. The role of a founder extends beyond their previous well-defined jobs. It requires them to shift their focus from solely considering "how" to build a great product or "how" to acquire customers. Founders now bear the additional responsibility of determining "what" product to build and, more importantly, "why" to build it.

Product Management as a core competency

In established software companies, Product Management sits in the middle of the three core disciplines of Tech, Business, and UX. 

By definition, Product Managers must build an appreciation and understanding of each discipline and become experts at weighing and managing trade-offs between them.

Good Product Managers tend to leave the implementation details (or the “how”) to the function-area experts on their team while doubling down on figuring out the product strategy and vision (or the ”what” and “why”) of the product.

I was fortunate enough to work as a Product Manager before starting my startup, Prodsight, and it greatly impacted how I approached building my product and the outcomes.

While I don’t think you need to have a Product Manager as one of the co-founders, bringing a Product mindset to your company and how you approach building your first product could be transformational. 

Over-indexing on Business

A common mistake business-oriented founders make is selling something that doesn’t exist. They would meet a prospective client and tell them what they want to hear by inventing features or entire products to close a deal.

Then they would return to their team and say, “We need to build this by the end of Q2 for the new client I just signed. Can we do it?”.

This is an extreme example but something I have seen in real life at various levels of severity.

Outside of the blatant disrespect to the engineering counterparts, the critical problem here is making up your product vision on the fly without considering the other two core disciplines of Tech and UX.

The act of soliciting business before the product is built is good as long as it’s done for research and validation purposes. Knowing what people will or will not buy can be a strong signal informing your product vision.

Unlike professional services, software products can be notoriously difficult to change. Once a team builds something, it’s literally etched in code and will likely stay there for many years. The sunk cost bias will make it very difficult to remove the feature, and now that one client commitment is driving your product.

Continuing this mindset creates a “feature-factory” culture where engineers become order-takers and simply churn out feature after feature without much overarching product strategy or vision. Talented engineers rarely want to work in such companies for long, which can become a problem in attracting and retaining talent.

Over-indexing on Tech

Founders with a strong technology leaning may possess exceptional technical skills and knowledge, but they are not exempt from falling into common startup traps. One of the most prevalent and detrimental traps is the act of building something that nobody wants.

Engineers, by nature, have a deep affinity for technology. Their passion and expertise lie in solving complex problems using their technical skills. Consequently, when engineers become startup founders, they often find themselves naturally drawn toward the "solution space." They focus on the technological aspects of their product or service, dedicating their efforts to creating innovative solutions.

In a typical engineering role, professionals work for someone else, and Product Managers make decisions regarding what to build. Their primary responsibility is to work with the technology assigned to them and ensure its effective implementation. However, when engineers embark on building their own startup, their perspective shifts significantly. Suddenly, every feature, every line of code, and every hour spent coding becomes an investment with potential consequences.

The decision to build a specific feature comes with an opportunity cost attached. By choosing to develop one feature, founders sacrifice the chance to work on another feature or task that might be more valuable or aligned with customer needs.

As founders with a strong technology leaning, balancing the product's technological aspects and market demand are crucial. While it is tempting to immerse oneself in the intricacies of technology, successful founders recognize the importance of understanding customer needs, market trends, and the overall business landscape.

Avoiding the trap of building something that nobody wants requires a deliberate and disciplined approach. It involves conducting thorough market research, gathering user feedback, and continuously validating assumptions. Founders must step outside the confines of the solution space and explore the problem space. By identifying real problems their target audience faces and aligning their technological expertise with these needs, founders can maximize the chances of building a product that resonates with customers.

Over-indexing on UX

Through the nature of their field, UX people are often more aware of their biases as a big part of UX is understanding human psychology and the science behind it.

Despite that, even some of the best UX folks sometimes succumb to decision paralysis and perfectionism.

UXers value real customer insights and often go to great lengths to understand customer needs and motivations in order to inform their solution. Then they bounce back and forth between the problem and solution space, trying to develop a perfect product that will solve real customer problems and do it well.

This can manifest in endless iterations of research or prototyping at the cost of committing to something and shipping it.

The reality is that no startup has enough time and resources to carry out “perfect” customer research in order to get a precise picture of customer needs. The same goes for designing the solution. Startups need to ship “something” in order to have a chance at getting traction. With traction, they can secure more resources and “buy” a chance at having another iteration.

How to achieve a balance between Business, Tech, and UX

Although the examples above are a little exaggerated, I hope I conveyed the risks of paying too much attention to one discipline at the expense of the others.

What’s clear is that you need to find a healthy balance between those disciplines in your team. So how do you do that?

Firstly, as a founder, you must recognize your own biases and leanings. What are you strongest at? What are your knowledge gaps? How does your past experience inform your decisions? Which disciplines do you find difficult to engage with?

Secondly, observe your co-founders (if you have any) and your team. What are their biases? You must ensure you have a healthy spread of voices across all three disciplines in your startup.

Thirdly, explore the mindset of a Product Manager and see how it can fill gaps between disciplines in your startup. Below are some resources that helped me develop my Product thinking.

• Inspired by Marty Cagan (book)

• The Mom Test by Rob Fitzpatrick (book)

• The Lean Startup by Eric Ries (book)

• What Customers Want: Using Outcome-Driven Innovation to Create Breakthrough Products and Services by Anthony Ulwick (book)

Have you noticed the tension between the three disciplines in your startup? Have you recognized your biases and how they impact your decision-making? Let me know in the comments!

Special thanks to Mark Hogarth, Alex McAndrew, and Natalia Filipiak for reviewing drafts of this post.

Unless you are sitting on a pile of cash from a lucrative past career, company sale, or inheritance, going without a paycheck while figuring out your company is a real issue.

Startup failure rates are high, and surviving the first year is critical. But YOU need to survive as an individual first so that your company can survive.

I recently wrote a post about the things I considered before quitting my job to start my startup Prodsight, and one of the common questions from readers was how I made it work without ending up on the street.

It took me nearly two years to restore my salary

I dug through my bank statements to determine the gap between my last paycheck from my job and when I finally started earning at least as much as I used to at my startup.

After starting my company, it took exactly one year and eight months to restore my salary. That’s nearly two years!

I was surprised, as it is way longer than I remember.

In this post, I will cover the steps I took to restore my personal financial equilibrium and the sacrifices I made between 2017 and 2019.

Building up the savings nest

Before I quit my job, I built up a cache of savings to see me through the early days of Prodsight.

My target was to save at least six months’ worth of savings, which I could tap into each month while I figured out ways to get some capital into the business to draw a salary.

My wife and I have always lived below our means, but I looked at all aspects of my spending to accelerate my savings rate and stretch my savings as far as possible during the “consumption” phase to see where I could make cuts.

Here are some of the things I’ve done to reduce monthly expenses:

• Cut going out/drinking/eating out to a minimum

• Worked from Starbucks, only buying their unlimited-refill filter coffee instead of renting office space

• Made lunches at home instead of buying takeaways

• Replace some meals with Huel (think protein-shake-like meal replacement)

• Cooked dinner at home instead of going out

• Cut any non-essential purchases like laptops, phones, or gadgets

• Bought fewer new clothes and shoes

While I tried to keep these “cuts” focused on myself, it inevitably impacted my wife. She also had to make sacrifices and cover any shortfall in our household budget. I am forever grateful to her for this.

Putting our spare room on Airbnb

While the cost-cutting measures allowed me to reduce my “personal burn” rate significantly, there was only so much I could cut.

We also decided to rent our six-square-meter second bedroom to Airbnb guests to bring in some extra cash.

We met some wonderful people through this experience, but eventually it started taking a toll on us, and we stopped Airbnb as soon as I started earning a salary again.

Taking on contract work

Reducing personal costs and dipping into savings made quitting my job and working on the startup possible, but it wasn’t a permanent solution.

Every month, my savings were dipping lower and lower, and all of the cost-cutting was starting to impact my quality of life. I had to start generating money from the company to pay myself.

Building a product that people are willing to pay for and making that enough to pay yourself a salary is not a small feat. It takes time to figure out which problems you want to solve. Designing and building software is a tedious process. You often get things wrong and have to go back to the drawing board. It was clear that I needed time to figure things out, and the quickest path was selling my labour.

A good friend, Jamie McHale, came to the rescue. He was running a technical consultancy, and one of his projects required a PHP developer. Mind you, I was a self-taught developer and barely qualified for the job, but luckily I could complete the coding tasks and got paid a decent daily rate for two days a week. This allowed me to earn enough money to cover my basic living costs and stop draining my savings. It felt like I froze time.

While my contract work was unrelated to my startup idea, it allowed me to spend the rest of my productive time figuring out my first product.

First product revenue

About three months after leaving my job, I launched my first mini-product/experiment called IntercomExport and started generating small amounts of revenue. It was a small app that facilitated data exports from the popular customer service tool Intercom.

It was an experiment that enabled me to learn from a niche group of Intercom users about what additional needs I could solve for them. I identified that many of these users were exporting data from Intercom to analyse trends in customer requests. That finding ultimately led me to develop Prodsight.

I know I’m glossing over this part of the journey as I plan a more in-depth post on product discovery and iteration. I want to keep this post focused on the personal finance aspect.

Raising the first round

When I reached around $1,000 in Monthly Recurring Revenue (MRR) from my product experiments, I began looking for external investors to help me expand the team and continue growing the product.

The problem was - I didn’t know a single investor. This is not uncommon for early-career folks like me at the time, as you don’t just bump into high-net-worth folks while doing your office job.

Luckily, the local startup community came to the rescue, and various folks made warm introductions to angel investors (shout-out to Martin Lind, Calum Forsyth, and Gavin Dutch). I started taking meetings and pitching my startup. I had a vague idea of the whole process and took it one step at a time while allowing conversations with other founders and advice from blog posts to help me guide me along the way.

As soon as the first angel investor said “yes,” the ball started rolling. I could leverage that initial commitment to onboard additional angel investors. Once I had the critical mass, I began working on the legals and moving towards closing the round.

I closed our pre-seed round of investment in February 2019 - and that’s when I could start breathing a little easier and start thinking about paying myself again.

Deciding how much to pay myself

Deciding how much to pay yourself is a common dilemma for founders. Part of this is resolving your own conflict of interest. As an employee, you are continuously optimising for maximum pay. However, as a founder and director, you must also protect the company’s interests, as maximising your salary might harm the company.

The general rule for founders is to pay themselves enough for living expenses. As the company grows or raises investment, the founder’s salary increases until it eventually reaches the going market rate. Investors like to see founders making personal sacrifices and investing sweat equity into the business as a signal of their commitment to the startup.

I paid myself the bare minimum for the first 20 months, averaging around £1,000 monthly. It's not the kind of pay you can easily survive on, and far below what any outside person would accept to run the company. But that didn’t matter because I was betting the company would become a success one day. The equity I had in my startup was where I was banking my potential future returns.

As soon as we raised the first round of funding, my salary was set by the new board of directors under the shareholders’ agreement. I proposed the number just above what I earned as a Product Manager. While I was underpaid, it was enough to live on, and I no longer had to stress about personal finances.

I can now focus entirely on building the company.

Special thanks to Martin Lind for reviewing a draft of this post.

So when I meet new people and the question of “what do you do” comes up, I secretly like it. I like it because it allows me to share a mini-version of my founding story and its core to who I am.

“I couldn’t leave my job to start a company.”

This is the most common response I hear. It’s a knee-jerk reaction to something people perceive as a large, uncertain, and unpleasant undertaking. I usually take it as a compliment, but in this post, I wanted to explore some of the considerations that made me take the plunge.

For context, in 2017, I left my job as a Product Manager to pursue a startup called Prodsight as a solo founder. In 2022, I successfully sold it, which now, six years later, validates that decision, but at the time I obviously had no clue how it would pan out.

This post is not meant to convince anyone to do what I did, but instead to offer a perspective on the factors that might lead one down the path of entrepreneurship.

Forces at work

Changing from stable employment to entrepreneurship is a significant change for the individual. It was certainly something I had to think through myself before leaping.

When considering a significant change, I like to use the Forces Diagram to break down the various factors involved. The Forces Diagram shows the energy involved in the transition from the current approach to a new solution. It includes two forces promoting the switch (push/pull) and two hindering it (anxieties/inertia). Push represents struggles in the current situation that drive the search for a better solution. Pull is the attraction to the new solution. Anxieties involve concerns and uncertainties about the new solution. Inertia refers to factors that make changing from the current situation difficult.

Push: Risk and Reward

Shortly after graduation, I got a Product Management role in a small boutique mobile development agency. I watched the founder work with awe and tried to absorb as many lessons as I could from him.

Less than a year in, he sold the company, and I witnessed years of his work pay off instantly. It planted a seed in my head as an example I could follow someday.

I was fortunate to continue learning from him when he and his co-founder invited me to join their new startup as a Product Manager. I could watch them build the company from scratch and play a significant role in the process. And I could do all of this with no downside risk of actually being a founder.

Jobs are low-risk, low-reward. This means that as long as you show up every day and do a reasonable job, you are guaranteed to receive a paycheck. There is not much volatility in that contract. Entrepreneurship has a very different risk profile and tends to be high-risk, high-reward. There is a very high likelihood that your startup will fail (in fact, 90% of them do), but for some that end up being successful, it can mean outsized returns in the event of a company sale or an IPO.

Once I internalised the lessons and my personal growth slowed, the reality of “risk vs reward” caught up with me. I wasn’t the founder of this startup. I wasn’t taking any risks, so I won’t share the rewards even if it succeeds.

It became clear that I had to take more risks.

Pull: Wearing multiple hats.

I greatly respect people who go deep into a subject and become experts. I love working with these people.

But that’s not me. Whenever I try to go deeper into something, I get bored and find it limiting. I immediately want to pick up something new.

At university, I deliberately picked the broadest degree I could - Business & Management. It was a perfect mish-mash of disciplines that were cool to learn about but didn’t prepare me to do anything specific.

However, the startup I worked at as a Product Manager was the perfect boot camp for starting my own company someday. Because the startup was so small, I could get involved in many of the activities that go into founding a company. Customer research, prototyping and building the first product, figuring out branding and growth, and implementing metrics.

This type of “skillset” is precisely what you need in an early-stage venture, so going down that path made a lot of sense. I loved wearing many hats, which was a big attraction to starting my own company.

Inertia: Sense of stability

Despite all the push-and-pull forces, I wasn’t ready to jump immediately. I loved the founders and my team. It gave me a social circle and an environment where I could try different things and create alongside intelligent people.

The regular, stable paycheck was something I relied on heavily. We have just taken out a mortgage to buy our first home and just got married. For most people, this would be the time to hunker down, and the idea of giving my 30 days’ notice was certainly weighing down on me.

Anxieties: Fear of failure

The most significant anxiety about leaping into entrepreneurship was the very likely event of failure, with the aftermath of burned-out savings, disappointment, shame, and finding a new job with the tail between my legs.

At the same time, that outcome didn’t seem that disastrous because I would have ended up pretty much where I started, albeit a bit bruised.

In case you are wondering, I didn’t have a fallback cushion. I come from a single-parent household in Lithuania. While my mom is a superwoman for raising my sister and me on a single teacher’s income, she gave us all with nothing to spare. My wife had a decent full-time job, but her income wasn’t enough to support both of us.

I might publish a separate post about all the steps I took to prepare to quit my job. In short, to make this work, I made a detailed financial plan and made a stop-loss agreement with my incredibly supportive wife. If I don’t start generating income before we run out of savings, I will shut down the startup and find a job.

We accumulated six months’ savings. We cut our expenses to the bare minimum. We Airbnb'd our spare bedroom for extra income. I leapt.

The leap

I have considered many factors when jumping, but I didn’t have the clarity of thought I have today, six years on.

It would have been wise to do the Forces Diagram exercise then. I’m also happy I didn’t, as I might not have ended up where I am today.

In summary, it didn’t come down to what I would lose by leaving my job. It was all about what I could gain by starting a company.

Special thanks to Renata Labude for reviewing a draft of this post.