Rod Hamilton is Chief Product Officer and Co-Founder at employee experience platform Culture Amp. He’s been at the startup’s helm for about 11 years now, and a Startmate mentor for about three years too. 

To kick off Startmate’s Open House, I had the pleasure of speaking with Rod about Culture Amp’s origin story, first product, third product, long-standing focus on community, decision to bootstrap and first funding round. He touched on how the team made their first sale, scrapped their first product, and overcame their fears and pursued venture capital investment.

It was a candid and inspiring 55-minute conversation, with insights galore. Here is an edited transcript for you to sink your teeth into. 

‍

Part 1: Culture Amp’s origin story

‍

Where did the idea for Culture Amp come from? How did you start the company?

Prior to Culture Amp, I spent many years in enterprise tech working for telcos, banks and other global enterprises.

If there was a theme that set me on the path for Culture Amp, it was that I worked on these tech transformation projects that often involved hundreds of employees, a multi-year journey, tens of millions of dollars… and you'd get one year in and you would look up and you’d barely moved the needle on the tech transformation. 

It was never the tech that was the challenge, it was always the people and culture side of things. 

I’d actually worked with Doug English and Jon Williams on one of these big projects, and we met Didier Elzinga on the journey. The four of us rallied around the idea of ‘a tech company that helped companies to be more successful by focusing on the people side of things’. We had a few bites at the cherry to get something that worked, but it was really just rallying around a problem that we all believed was worth solving.

‍

When you decided to found a startup, how did you know you were solving the right problem, and then, how did you know you were doing it with the right people?

It was actually the other way around for me. What I mean by this is I didn't have huge ambitions to start a startup. It began with building conviction in the people that I was going to work with. 

As I said, I met Doug and Jon on a couple of those big transformational projects. We built trust with each other. We liked each other’s working styles. We felt we were a pretty good team. Then we met Didier along the way. He'd been working on the concept behind Culture Amp for a while already. 

For me, it was the combination of a team I could trust and wanted to work with, and a problem space that I was super passionate about.

I was still a reasonably risk-averse individual back then. I needed a fair bit of pushing from my co-founders, and probably a little bit of pushing from my wife and my brother too. 

In the end, the thing that gave me the most conviction was thinking through the worst-case scenario.

Thinking back on it, I always felt like it was this really big decision to quit my job. I thought it was going to be super scary. But it wasn't a big deal. If things go pear-shaped one year down the track, you ask for your job back. Or, if you've got a pretty good network, you ask for a bit of help. I was quite fortunate in that respect.

Even when we weren't earning any money, and we weren't getting salaries, it was just nowhere near as scary as I thought it would be. 

‍

How did you ensure you were all on the same page? What crossed your mind when you created and signed your first co-founder agreement?

People often say, ‘four co-founders sounds like a lot’, but we’ve been super lucky, because the combination really works for us. From day one, Didier and I were more focused on customers and product, and Jon and Doug focused far more on engineering and building out the product itself. We really complement each other skill-wise.

But I think the key thing — and this comes back to basic team psychology — is you have to aim for trust from day one. 

Early on, we set everything up to be as equitable as possible across the co-founding group. We also just hung out a hell of a lot outside of work too. So we had a real foundation of trust. Once you have that foundation, you can have arguments, and you'll still be friends at the end of the day. 

And what was the first thing that crossed my mind when I read the first agreement? I remember thinking, ‘shit, these guys are ambitious’. It was a pretty big plan from the start!

‍

Your point about ambition is interesting, because early-stage co-founders are often concerned about being on the same page from an ambition perspective. How did that play out?

I think it really helped us.

In some of those early discussions, one or two of us were super ambitious in wanting to take on all the projects and all the customers. I was less ambitious. I would say, ‘if we are going to do this, this is what it means, and we need to think about X, Y, Z. If we say yes to this, we have to say no to all these other things’.

Sometimes, when you want to swing big, you have to come to terms with what it will take to get there. We probably needed that balance. I think it was a healthy blend. 

Over time, of course, I got more ambitious. I'm definitely more ambitious now than I was when we started. 

‍

Part 2: The first and third product

‍

What was your first product and how did you build it?

Our first product wasn't great. If there was a book for ‘how not to do it’, we followed that well. 

We built our first product in the performance management space. We were trying to blow up the annual performance review and turn it into a far more continuous cycle for companies, with a focus on manager coaching rather than performance evaluation.

We built that product out super quickly, in two or three months. We had non-paying customers on board, and teams using the product. We had reasonably good customer retention, with teams coming back and using the product day in and day out.

We made our first sale a few months in. 

To this day, I like to brag that I made Culture Amp its very first sale. It was a huge, $400 annual subscription by a not-for-profit. They never even signed into the platform. Not even once! But they did pony up the cash; I remember taking that cheque to the bank! 

Then, about six months in, we landed a reasonably big customer, and they loved the product.

Unfortunately, that gave us a lot of hope and encouragement to persist. We thought we just needed that one extra feature, or to change one thing, and then with one good customer, the rest of the world would figure out that we’d created a wonderful product.

It took us nine months to figure out that while we could get users, we couldn’t get to the buyer. So we had a product, but we unfortunately didn’t have a business model that worked. 

‍

When did you realise it was time to kill that first product?

Initially, I was really reluctant to kill the idea. I think it was because I'd spent so much time thinking about how the product would have helped me in my prior roles. 

What actually tipped me over the edge was my brother saying to me, ‘how long do you want to spend all of your own money on something no one else is willing to pay for?’ Obvious right?

The reality was, we just didn't have traction. You don’t know what traction feels like until you actually get it. It has been so dramatically different with our subsequent products.

There was also the fact that we could get customers on board, but when we got introduced to the buyer, we weren’t successful in that interaction. They would say it was too big of a change management exercise for them, and it actually got to the point where they shut their teams down from using the product. 

Once we came to terms with this, it became fairly straightforward to say, we need to swing at something else.

Also, we were running out of money pretty quickly.

‍

Your distinction between buyer and user is very interesting. How did this learning influence your next products?

It had a huge influence, and it still does today. 

If you think about what we are actually trying to do with Culture Amp, we’re trying to help companies be more successful by improving the behaviours of all employees. We're trying to change culture, so that's fundamentally about changing behaviours. 

So even though we sell to HR, and they're the main buyer, we need to get managers and employees on board, to use our platform on a regular basis, and focus on improving whatever they need to be more successful.

What we did differently with our third product — which was essentially an engagement survey platform — was we validated that our buyer was interested before we started building anything. 

It was a dramatically different approach to the first product that we built. 

We didn't do any coding. We put together a six-page PDF document, which was basically a prototype of the platform that we we're going to build. We said to ourselves, over a two or three week period, we're going to interview 20 CEOs or heads of HR, and if we can get 10 of them to sign a contract saying they’ll buy this thing, then we would build it. 

We were actually trying to sign up customers before we had any sort of product. 

We didn't quite hit our numbers. I think we only interviewed 10, and we had four actually sign up. But we rounded up and cut ourselves some slack, because it was the first time we had customers. We just didn’t have a product, so we started building.

That ability to get to the buyer and that willingness to pay was just critical in those early days. 

We still think about this today when we are building features. We constantly think, ‘if we build something for managers or individuals, is this going to be relevant to the buyer as well? How can we get value to the buyer too?’

‍

If you didn't even have a product, what were you selling to these people? When they did decide to sign a contract, what happened next?

If someone signed, it meant we had to build the absolute bare minimum of essential things for the customers to be successful with the next step. 

The very first version of the engagement survey portion of our platform was literally the form (with 50 or so questions) that the employee fills out when you launch a survey to them. 

I was building scripts. I'd get every employee email address, and I'd run a script that would send them all links. It was pretty ugly. And then the employees would fill out the survey. 

I would then take an export of their responses, and give them to our chief scientist Jason McPherson, who was our first employee at the time. He would put it into a stats program, and bash out some really ugly PowerPoint presentations, and then we'd present these to the customers. 

So we were really just one or two steps ahead of our early customers in terms of what they needed in the platform. 

The by-product of that was it was an incredible way to learn what was important to them.

Working with customers this way, and actually taking them through a PowerPoint presentation rather than building a report, showed us very quickly which concepts resonated and which concepts didn't resonate.

Part three: Using community to learn and scale

‍

Honing in on your first 100 customers, was there a particular go-to-market motion you tried to pursue?

A big part of our go-to market in the super early days was ‘don't sell, ask for help’. People don't want to be sold to.

One of our early hacks was to go to San Francisco for two weeks, and get on LinkedIn and look for any head of HR who'd been in the role for six or seven months, and send them an email. We’d say: ‘We're just in town for a couple of weeks. We want to learn. Can we show you what we're working on? We'd love to talk to you about your take on this problem.’

And more often than not, they'd be super passionate about the problem space, and say yes.

Then they would connect us with a bunch of other community members or colleagues. These introductions worked incredibly well for us.

So my advice is ask for help, don't try to sell too hard. Once you get that help, it often turns into a sale anyway, but the most valuable thing you can get in the early days is learnings.

‍

I'd love to double-click on the idea of building through community. You were ahead of the curve when you started the People Geek movement. Was this an intentional part of your strategy?

I don't think it was totally deliberate when we first started it. I’d like to say it was. 

People Geek came about when we were trying to figure out what to put on a T-shirt before one of our early trips to San Francisco. 

We saw a guy with a New Relic T-shirt that said ‘data nerd’, so we tried to do our version of it, which was ‘People Geek’. I absolutely hated it at the time.

Then, when we were in San Francisco, we did some meet-ups and called them ‘Geek-Ups’, and the people coming to these events really resonated with the idea of People Geek. They would say, ‘I’m a people person, and I like to geek out on data’, it became part of their identity. Some HR people even made their own versions of the t-shirt.

These Geek-Ups became an incredible growth factor for us because even when we weren't in the room, people would continue talking about us and sharing their experience with the problem we were trying to solve. 

And that’s an important point: don't try to build a community around your product, try to build a community around the problem you're trying to solve.

We built a lot of momentum behind the People Geek community. At one stage we were doing multiple Geek-Ups every week in different cities across the world.

‍

It sounds like there are really important links between community, go-to-market, sales, marketing and product development. How did these links actually work in practice?

It's interesting talking about this now, because we haven't done any of these in-person events for a couple of years now. But a big part of the way we approached it was to get everyone involved in these events. 

Geek-Ups aren’t just something the community team runs. I always encourage our product managers, designers and engineers to go along too, because these events are an incredible source of insight and feedback. 

If you think about it, you've got the perfect blend of attendees at these events. 

You've got customers who are using the product, and once they know there's an engineer in the room, they'll make feature requests or give feedback. 

Then, you’ll often have people who know they've got this problem, so are prospects. The fact that you've got other customers in the room typically helps with the sale itself. 

And third, you’ll typically have people who are not customers and not necessarily looking to solve the problem just yet, and they’re another source of research for product teams.

Part 4: Landing an enterprise customer

‍

In past conversations we've had, you’ve said your first 100 customers were of an SMB size, and then you jumped to enterprise customers too. Can you talk about this leap?

A few years in, our sweet spot was fast-growth tech startups, up to companies with 500 or so employees. We'd built a really good product for those sorts of companies. 

We didn't make a deliberate decision that we wanted to go after the big end of town, but the opportunity presented itself.

Adobe contacted us, purely inbound, and Jon suggested he fly to San Jose and meet with them. He walked into a room of about 30 people, and did a demo, and absolutely nailed it. They really wanted to work with us. 

We then had a big decision to make, because to be able to support Adobe, which had 15,000 or so employees at the time, we had to rebuild the product very quickly. I think we had about 90 days to rebuild the platform. 

The decision was, do we double-down on the SMB and mid-market or do we try to scale to the enterprise? 

Initially, it felt like it was this big yes or no decision, until a member of the team asked ‘what needs to be true to be able to do both?’ 

That led to us itemising out a whole bunch of assumptions, which we reality tested. In the end, we managed to find a way whereby we could build out what was needed for Adobe, but actually make it really relevant for the rest of our customers and improve their experience in the process. 

It turned out to be a really pivotal moment in our growth, because we managed to support Adobe, and they had a wonderful experience on the platform, and then they became this incredible marquee customer that really helped us lean into the bigger end of town over time.

‍

How do you go about dealing with custom feature requests from enterprise customers? How do you make sure you're building the right things?

It's still a challenge today, to be honest. Today, some of our biggest customers have more than 100,000 employees. 

When a very big, valuable customer comes along and says ‘we need you to build this’, there’s a fair bit of weight to the request. But the risk is that you say yes to too many of these requests and it just whiplashes your roadmap from side to side. It actually makes it very hard for you to remain the master of your own destiny and actually execute your roadmap.

My rule of thumb is that most of the time, you should say no to feature requests. And the reason you're saying no is because you're saying yes to something else.

Behind every no, there's a yes, which is hopefully something that’s more strategically important to you, and helps you remain on your own path. 

But it’s never a really simple decision. In the early days, sometimes it's totally fine to say yes to produce that runway. You've just got to be deliberate in how you make the decision. 

Part five: From bootstrapped to Series A

‍

You bootstrapped at the start of your journey. Why did you choose this route, and what are the trade-offs in your mind between raising or bootstrapping?

It's an interesting thought process. I think we were bootstrapping for about three or four years.

A big reason for this, early on, was the fear of losing control. We worried that an investor would come in, and we’d suddenly lose control of all our decision-making rights and be put on a certain path. That was one of the fears I had.

The tipping point was actually a conversation with Scott Farquhar, who was one of our advisors in the early, early days. He said to us: ‘You have a product that your customers love, you have no clear competitors, you've got a plan and clear blue water in front of you, it's time to put the foot down, because others will notice that traction in time and other startups will come into the space.’

And that was when we raised our Series A with Felicis.

Given the time again, I would probably raise a little earlier. It enables you to start to get specialists into the business who are really good at the sorts of problems you need to solve. Up until then, we were a whole lot of generalists who were good at a bunch of different things. 

Funding really allows you to lean into some more specific things you need to scale.

‍

Once you decided to raise, how did you tactically go about finding your lead investor?

The process was basically, go to San Francisco, and meet as many investors as you can, until you find someone who gets it.

I remember meeting with investors who said: ‘Why the hell would a company survey their employees and ask them for feedback? That doesn't make any sense at all.’ 

You have to work through it until you find an investor that really resonates with your idea. And that was the thing about Felicis for us. Aydin Senkut and Wesley Chan really believed in the culture and what we were trying to do. 

Personally, I remember I found the investing process really confusing the first time through. It was an intimidating process.

I would read venture deals, get super confused, google it, finally understand what it was that they were talking about, and then you'd have no idea if you actually were getting a good deal or not. 

What helped us is going and talking to founders and people who had been through the investment process, especially with the particular VC you're going to strike a deal with. Lawyers are useful as well. You’ll always get different opinions, so pick who you trust, and focus on their advice.