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.

Subscribe now

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 remember.

Subscribe now

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 the ambassador of my startup, and I realized that unless I get over the hump, I won’t be able to move my company forward.

Once I made that realization, 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 our product was strong enough when pitching potential customers. I was not confident my background was impressive enough when pitching investors. I was not confident in my skill to handle a conversation where 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 visualized on a spectrum. I moved from the “Absolutely paralyzed” 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. The outcome of each call was binary.

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 day-to-day look like? What challenges are they facing on the day-to-day? 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 if we could solve this customer’s problem.

I started actually enjoying these conversations. I even reached the point of looking forward to doing 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 analyze 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 defense, 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 practiced 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 grueling 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 become 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.

Subscribe now

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 most gloomy days, I would fear that the whole thing would fail, burn through my savings, and be left with nothing to show.

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 realized 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 that my job provided and that I was taking 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 defacto 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 favorite 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 have 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 to 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 minimized 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 that I hadn’t 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 be accountable to myself. 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 what progress I made on my startup, what challenges I encountered, and what next steps I wanted to commit to.

The knowledge of the constantly looming meeting with Martin meant that I always had the incentive to make progress with 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 startups is as much a psychological puzzle for founders as it is about skills, knowledge, or finance. I surprised myself by craving things I was seemingly running away from, like 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" it should be built.

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 time gap between my last paycheck from the job and when I finally started making 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 my steps to restore my personal finance equilibrium and all 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 every month while I figure out ways of getting some capital into the business to draw a salary.

My wife and I always lived below our means, but I looked at all aspects of my spending to accelerate my savings rate and stretch it as far as possible in 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 is 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 bringing in 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 for that to be 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 must return to the drawing board. It was clear that I needed time to figure things out, and the quickest path was selling your labor.

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-thought 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 facilitating data exports from a popular customer service tool Intercom.

It was an experiment that enabled me to learn from a niche of users of Intercom about what additional needs I could solve for them. I identified that many of these users were exporting data from Intercom to analyze 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-worths while doing your office job.

Luckily, the local startup community came to the rescue, and various folks made warm introductions to local 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 along the way.

As soon as the first angel investor said “yes,” the ball started rolling. I could leverage that first commitment and onboard some other 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 optimizing for maximum pay. However, as a founder and director, you must also protect the company’s interests, as maximizing 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 on the company becoming 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 determined by the new board of directors as part of the shareholder’s 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 could now entirely focus 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.”

Subscribe now

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 obviously, at the time, I had no clue how it was going to pan out.

This post is not meant to convince anyone to do what I did but instead offer a perspective of 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 certainly was something that I had to seriously think through myself before leaping.

When considering a significant change, I like using the Forces Diagram to break down the various factors that go into it. The Forces Diagram shows the energy involved in switching from the current way 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 all the lessons I could from him.

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

I was fortunate to continue learning from him as he and his co-founder invited me to participate in their new startup as a Product Manager. I could watch them build the company from scratch and be a significant part of 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 internalized 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 risk, 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 activities that go into founding the 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 pull and push forces, I wasn’t ready to jump instantly. 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 and stable paycheck was something I was heavily relying on. 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 me and my sister 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 on all the steps I took to prepare for quitting 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 by the time we run out of savings, I will stop 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 leaped.

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.

Product is at the core of every startup. When your product solves a customer’s problem, they are happy to pay you for it, which becomes your business's foundation. But navigating that first product is the ultimate test and one of the main reasons 90% of startups fail.

My whole career revolved around building products in startups. I created products as a solopreneur, as the very first PM hire, as part of a group of PMs, as a venture-backed founder and as a product director in a scaleup. Regardless of the industry, company stage of the company or available resources, the core mission was always the same - figure out the customer’s problem and build a product that solves it before running out of money.

Whilst not all products I built were successes (welcome to the world of startups!), along the way I picked up some crucial lessons that I’d like to share with the community.

If you are an early-stage startup founder navigating your first product and building out your product team, this newsletter is for you.

Some of the topics I’m planning to cover in this newsletter:

• Customer Development

• Product Discovery and Experimentation

• Developing product strategy and vision

• Building the first product team

• Building the first product process

• Founder-PM relationship

• Product-market fit

Topics we covered:

💸 Selling my startup
🎢 Transitioning from a tiny startup founder to a product lead at a scale-up
🎩 Giving up "many hats" for a more focused and defined role
🕵️ Importance and practice of product discovery
🏎 Maintaining speed whilst scaling product teams

Hope you enjoy the episode and please share your feedback in the comments 😀

Listen to the episode

In this episode, we talked about how multiple channels and siloed feedback can be a company’s biggest customer feedback analysis challenge and how good data hygiene is the foundation of data collaboration across teams.   

We also dove into why you should rethink your churn exit survey and what you can do instead. Lastly, we discussed how you can analyze churn against support tickets and feature requests.

The Back Yourself Show presents a leading conversation within the startup community globally that is actively helping over 10,000 founders and entrepreneurs in the first phase of their journey as business operators.

I hope you enjoy this podcast episode.

The program was top-notch. Babson is constantly rated #1 for entrepreneurship and the faculty are all ex-operators with decades of experience in starting, running and selling companies.

There were three themes that stuck with me as I think about taking my startup Prodsight to the next stage so I decided to share them in this short post.

1. Biases will literally kill you

In a session on decision-making led by Dwight Gertz, we talked about how various psychological fallacies or biases get in the way of us making good decisions.

I was already aware of several biases (e.g. confirmation, recency) as that’s what we help teams overcome with Prodsight by turning “mushy” qualitative customer feedback into quantitive trends.

However, what stuck with me is a case study of the Tenerife airport disaster. While taking off KLM flight 4805 collided with Pan Am flight 1739 halfway down the runway, killing 583 people. The KLM captain was Jacob Van Zanten, KLM’s chief flight instructor who had just returned from a six-month safety course. It was concluded the pilot took off without clearance, thereby causing the crash. But why?

Biases like loss aversion (our tendency to go to great lengths to avoid possible losses), value attribution (our inclination to imbue a person or thing with certain qualities based on initial perceived value), and the diagnosis bias (our blindness to all evidence that contradicts our initial assessment of a person or situation) are believed to be the main contributors.

We can’t avoid the effect of bias altogether as these processes often work at the subconscious level, but by being aware of the full range of psychological fallacies and by fact-checking important decisions we can increase our chances of success.

2. Focus, focus, focus

Another lesson that stuck with me is the importance of staying focused.

If you hold a magnifying glass over a pile of dry leaves on a hot day, nothing will happen as long as you keep moving the magnifying class. But as soon as you hold the magnifying glass still and focus the rays of the sun on just one leaf, the whole pile of leaves will erupt into flames.

In the early days of a new venture, it can be very tempting to pursue a range of different opportunities at the same time to see “what sticks” because you don’t have the historical data to determine which idea is the most worthwhile. The challenge is that at that stage you also have incredibly limited resources which leaves even less room for error. The longer you spend spreading your bets, the lower the chance of success as none of the opportunities get the attention they deserve.

One approach to improve the chances of success early on is to methodically experiment with a small number of ideas to gain data and conviction and then ruthlessly prioritize which one to pursue with full resources. Obviously, it’s easier said than done.

3. Why should people invest in you?

Another key message that was per-mutating across all the sessions was the idea that you should be comfortable selling yourself. You must be able to quickly and succinctly articulate what about you makes you deserving of the investment of time and money from other people over anyone else.

This is one is personally hard for me as I’m hard-wired to think “talking about yourself = bragging”. I grew up in an environment where bragging and being full of yourself were frowned upon and modesty was encouraged and respected.

However, as long as you stick to facts (achievements attained, skills gained, relationships built) and stay away from opinion (your view of why you’re the greatest) it is not bragging. It’s something that I’m working on to internalize.

Overall, it was an amazing experience to learn from experienced lecturers and other entrepreneurs in the cohort and I’d love to do a longer course at Babson someday. I’d like to thank the good folks at the Scottish Enterprise, Unlocking Ambition and Entrepreneurial Scotland for this amazing opportunity.

Do any of these lessons resonate with you? Let me know in the comments or via Twitter @tadaslab.