Validation

This is the second chapter of Kommon: A Startup Story, a set of key lessons for first-time founders told through the story of the successes and failures of my business.  

I have been told that putting these lessons within the full narrative of an early-stage startup, including real customer data and product feedback, has meant they really resonate for first-time-founders in helping them navigate their own startup journeys. The introduction to the series with further details on why I wrote it can be found here.

Introduction

I had previously been part of a product launch which involved spending thousands of dollars on software development without truly knowing what our users wanted.  I wasn’t in a rush to repeat the experience.

One of the most exciting challenges in product development is working out how to validate ideas quickly, efficiently, and cheaply.  I was excited to get started on this part of my work.   

I also knew that doing this well would be key to attracting a technical co-founder who could build the product. I wanted a full-time co-founder who I had no money to pay, which is always a tricky pitch.  I knew that compelling evidence of future paying customers was probably the best currency I had (this would prove to be correct).

I had done customer discovery and interviews before and had a rough plan for the next few months:

1. Initial customer interviews to discover problems
2. Design a prototype (I hadn’t done this before)
3. Second customer interviews to validate prototype and get commercial commitments

This chapter is the story of how even though I ran a good process, my biases got the better of me.  I gathered a good dataset but I saw what I wanted to see in the data, rather than what the data was showing. 

This erroneous analysis led to the wrong product and undermined the entire first 18 months of the company.

The Initial Customer

I wanted to build software to help people managers excel at their jobs.  My initial hypothesis was that managers could be both my users and my initial customers.  

I had watched companies like Slack, Trello, and Asana find their way into companies with a self-serve model, build a foundation of users, and then use that initial user base to pitch enterprise contracts.  Their apps were for project management, but team management seemed analogous.  If managers weren’t getting the support they needed from their organisation, could they not also turn to a software solution they could procure themselves?  I knew at some point I would need to talk to a central function about enterprise procurement (either HR/People or Operations) but I hoped I could build a critical mass of users inside companies first.

There also seemed to be a gap in the market.  If you were an individual manager who wanted one of these tools, they were hard to get. The larger firms in this space (Lattice, 15Five) were enterprise-focussed and had a minimum account spend of roughly $2500.  I thought I could start by focusing on those managers who were underserved both by their organisations, and by the market (more on this strategic error later).

So my customer discovery had two aims: 

1. Establish the most significant challenges managers had
2. Establish whether managers were able to pay for this type of product directly 

I designed a set of questions that I thought would give me those answers and started interviewing.

First Customer Interviews

I barely stopped for Christmas and New Year before having my first customer discovery conversation on 3 January 2020.  

I’m not going to go into detail here on all the ‘do’s and don’ts’ of customer discovery.  This has been covered extensively by others and resources like the Mom Test are excellent.

Over the next few weeks, I would have conversations with nearly 40 people across 27 different companies, from new tech startups to centuries-old global banks, collecting 40 data points on them, their companies, and their approach to people management.  It was fascinating. What I learned became the foundation for much of the next four years. 

Although various studies emphasise the invaluable role of good people management in organisations, it’s rare that anyone in the role has the time to think deeply about it.  I know I didn’t, even with my enthusiasm for the topic.  These interviews and my research gave me an expertise above the majority of users and customers I would be selling to.  They also provided some great horror stories - the organisation basing their wellness survey on a template from a prison was a particular highlight.

I’m not going to go through all the data but here’s some of the high level points from the managers I spoke to:

• Importance: I asked how important they felt people management was in their organisations on a scale of one to ten, where one was ‘it doesn’t matter at all’ and ten was ‘it’s the most important factor in the success of the organisation.’  The mean of these responses was an eight. 

• Approach to the role: 84% of the managers I spoke to said they were either comfortable (65%) or mostly comfortable (19%) in the role.  This lowered significantly when speaking to managers in their first two years in the role, or in companies of less than 150 people. 

• Doing better: 55% of the managers I spoke to said they wanted to improve in the role.  The most commonly cited area was their ability to develop their teams, followed by managing underperformance.

• Challenges: these managers had a multitude of different challenges they were grappling with.  I counted 21 separate issues.  Management practices were very inconsistent, particularly around holding 1:1 meetings with team members, and gathering feedback.

• Existing solutions: despite the challenges, 30% of the managers had no assistance in the role.  The remaining 70% had had some form of training, but only 20% of those respondents said their training had actually been helpful.

• Finding solutions: despite the lack of assistance, 60% of managers didn’t look for their own solutions.  They mostly tried to figure it out and learn in the role. 

• Accountability: of 20 managers I asked about whether they were directly appraised on the quality of their management, only 1 said yes.

• The product: at the end of each conversation, I described the hypothetical software product I was thinking of building.  73% of managers said they would use it, a further 9% said they would trial it, and 9% said ‘maybe’. 

I mention these points because I think they’re a good example of how you can tell very different stories from the same information set.

My Initial Conclusions

If you were looking for data to support the case for building a self-serve SaaS company, you could find it in these numbers.  

One credible story might be:

‘Managers think their role is important and they want to get better (particularly at developing their teams).  There’s lots of inconsistent practice that could be improved, existing solutions don’t exist or are failing them, and they are willing to trial and pay for a product which would help.’

This was essentially the story I told myself. 

However, in hindsight there’s another story in these numbers which might read like this:

‘Most managers feel comfortable in the role, and even though they’d like to improve, don’t take it upon themselves to find any solutions.  The exception is first-time managers, often in smaller companies, who feel the challenges much more acutely.  These challenges are principally knowledge-based (they don’t know how to approach the role) rather than efficiency-based (they know how to do it, just want to do it faster).  Many organisations recognise this and often provide first-time managers with management training to fill in those knowledge gaps, but it isn’t effective.’  

Rather than building a self-serve SaaS company, the right product here seems to be an excellent first-time manager training course, sold at an enterprise level.  Spoiler: after a year of building, selling, and pivoting away from SaaS products, this would ultimately be how Kommon succeeded (see Chapter 5).  But the answer was already there in front of me.  I just didn’t want to see it because it wasn’t the SaaS company I had set my heart on building at that moment.

If most managers felt comfortable in the role, and weren’t looking for solutions, they probably weren’t going to look for a self-serve SaaS.  If those who needed my product most were new managers, paradoxically they were likely to have less authority in organisations to pay for it.  These were things I didn’t want to reckon with, but would have to much later.  

But for now, I wasn’t thinking like that.  I had Story 1 to tell myself, it was a good story, and I was emboldened to begin designing a prototype I could take back to my users. 

Design and Prototyping

I’m not a designer, but I’m not design illiterate.  I have a good eye, and have been part of the feedback process for well-designed products in the past.  

What I didn’t know was how to design, and I needed to put together a prototype.  I wasn’t too worried about this step though. I had the time to teach myself and I was excited to add some rudimentary prototyping to my skill set.  

Fortunately, the right tool was also rising to prominence at the same time.  Figma was growing in popularity in the design community, challenging Sketch, InDesign, InVision and others.  It was just what I needed.  It took about a month from April to May, but I had a fully working design prototype I could take back to my customers.

The Product 

My initial vision reflected what I had heard in my customer interviews.  I found this in notes from the time:

‘Managers want a collaborative solution so they can work with their direct reports to develop their careers by better collecting and storing information to tell the full story of an employee’s progress.’

I believed that by standardising managers’ approach to basic managerial tasks - setting goals, having 1:1s, collecting feedback - and putting it all in one collaborative place, I could help them be better bosses. 

I built a full working prototype I could click through to demonstrate the various features.  

An unfinished pitch deck from June 2020 which I put together to focus my thoughts (a bit like an Amazon working backwards press release) shows the direction of travel at this point.  The tagline was ‘Manage your team together’ - emphasising again the collaborative angle that I thought would help position the product.

The key areas I said needed solving for were:

• Consolidation:  managers want one source of truth which tells a coherent story of their reports’ progression.  Currently information is disparate and gathering it when they need it is inefficient and time-consuming.
• Collaboration: managers want a collaborative approach where the report and the manager can work together on professional development.  Current relationships can feel hierarchical and at worst, adversarial.
• Written Record: managers face numerous scenarios where they need a detailed record of an employee’s performance, e.g. for reviews, disciplinary proceedings, managerial/HR changes and promotions.  Informal record keeping means they currently don’t have it, and make decisions based on incomplete information.

Second Customer Conversations

By late May I had a Figma prototype to show to the customers I had previously spoken to earlier in the year.  

As you might recall, the world had also changed somewhat between March and May 2020.  In a devastating pandemic, e-mailing people to ask if they could review a prototype for a management app seemed trite, insensitive and borderline offensive. 

But on the other hand, if I didn’t send those emails, I couldn’t progress, and people were still working. So I swallowed hard, and I sent a series of very considerate follow up emails. I was pleasantly surprised at the positive response. I think people were just happy to engage with something novel. 

According to my records, I managed to do 18 prototype interviews with customers from 11 companies.  Some of the comments were very enthusiastic:

‘“Sounds like a dream.  I want to be able to provide you with constructive feedback but there’s nothing that comes to mind that you have not thought of at this stage, other than to say it sounds really great and when can we have it”  Product Manager, Tech Startup

”I’m excited, it sounds like it could be really helpful for poor people like me” Manager, Digital Marketing Agency

“It definitely feels like it is a need, the features that you have mentioned would definitely be very helpful” Senior Manager, Tech Startup

Of those 18 interviews, 8 managers  from 6 companies said they would trial the product.  This hit rate (44%) convinced me to:

1. Proceed with looking for a technical co-founder
2. Look at recruiting a waitlist of other managers to trial the product too.

I felt like I was gaining momentum.  It was also time for a name.

Something in Kommon

I didn’t want to spend too much time on a name.  In previous experience, names are something you grow into.  Even the worst names take on new meaning as they become associated with their owners’ achievements.  Arctic Monkeys is an awful name for one of the biggest bands in the world and no-one seems to mind too much.

I was just looking for something that:

1. I could link to my product: you often get asked ‘why the name’ and a good story doesn’t hurt.
2. Had no more than three syllables and two words: any more makes it less memorable. 
3. Wasn’t already taken: either by competitors, or those who had the relevant domains.

I did a simple exercise where I just started scribbling down words and phrases which had come up in conversations with customers about the topic of people management and my product (AI will now make this task much easier).   

Given that people management is a well-trodden topic, most of what I had failed point three.  Exploring second order themes of collaboration, team-building, copilots, coaches etc. also wasn’t very helpful.  Again, these themes have been mined for decades by companies. 

But with enough persistence, I found myself coming back to this idea of managers and their team members working together, sharing information and ideas - working in common.  I started exploring altered spellings and a quick search found that my only competition for Kommon was a small ebike company.  

I had my name.  The logo didn’t take much time either.  A ‘K’ in a blue square and we were done.

Since Kommon was incorporated, there is now a ‘Kommon’ innovation studio in Montreal and also an advertising agency in Mumbai.  Word is spreading. 

Key Lessons

• Be aware of your biases:  I filtered the insights I received from my customers through the lens of what I wanted to build.  This fundamentally undermined our product strategy from the start.  Going back and looking at the data I collected in 2020, I had everything I needed to build the right product - but I didn’t perceive it at the time because I saw what I wanted to see.

• Get others’ opinions: following my customer conversations, I would have been less likely to draw erroneous conclusions if I’d discussed them with the right advisor or mentor.  I didn’t feel I had this type of person in my network at the time, and thought it would have been too time-consuming to find them.  In hindsight, I should have spent the time looking.  There are lots of people (myself now included) who are happy to give their time to advising aspiring founders.  I think I would have been able to find various voices who could have given me good advice at this crucial time.

• Talk about product adoption: although I discussed with my customers how they would pay for my product (and received positive responses) we didn’t discuss how they would go about adopting it from scratch in their team and organisation.  I think if I had asked more detailed questions about this, it would have highlighted some issues with enterprise adoption which later stymied the growth of the product.

• Prototyping is awesome: the sophistication of contemporary prototyping tools means you don’t need to spend any money on development to present potential customers with a compelling vision of your future product.  

• Be wary of ‘gaps in the market’: I used to think that gaps in the market were to be charged into, but now I approach them warily.  Some entrepreneurs do have unique market insights which enable them to create a whole new product category, but they tend to be the exception.  In most cases, some other bright founder will have spotted the same opportunity you did, you will have competition, and you will just have to outdo them.  That’s fine.  If you spot a ‘gap in the market’, it might just be that there is no market.  In hindsight, I believe this to be true for self-serve SaaS for people managers.

• Ask for referrals: I had some of my best customer interviews by being referred on from initial interviews.  If you have a conversation which goes well, always ask if they know anyone else you should speak to.

• Love your customer as well as the problem: a lot of startup literature says you need to fall in love with the problem you’re working on, because you could be looking at it for years.  But you don’t have to spend hours in meetings with problems, or answer their queries, or think about how their lives work. You do have to do that with your customers.  One of the main reasons I enjoyed building Kommon was because I got this right.  I loved speaking to managers and working out how best to help them run their teams, and this sustained me for years.

• Think just enough about names and logos: coming up with an initial name and logo shouldn’t take more than half a day.  Unless you really mess up the process, you will grow into it. 

‍