How CEO Camille Hearst Built a Startup

You have an amazing background, working at Apple, Google and Youtube, among other stand-out startups. These places are known to have high-functioning, elite teams that produce some life-altering products. What do you think made those teams work in terms of process and attitude?

Camille: I feel really fortunate to have had extended work experience at two of the most amazing tech companies the world has seen — at Google and at Apple. And what was really interesting to me was how differently they functioned and they operated and how they were both incredibly successful in their own way.

When you read a lot of the advice on the internet and you see how companies are set up, there’s a lot of mimicry, which is great because mimicry is a good shortcut — looking at someone’s success to see how they’ve done it, and then to trying to do that yourself. The other way to view that is pattern matching, which can sometimes end up being almost like a form of groupthink. Many people think, “Oh, this is how things are done and this is how you’re successful,” which is not always necessarily the case. There is definitely more than one way to do anything, and more than one way to be successful.

Apple and Google literally felt like the antithesis of one another in how they operated and in how you got things done. They cared about different things, looked at different metrics and had different priorities in terms of problem solving. Having gone through and experienced both sides, I feel like I’m better off for it. I have perspective that no, you don’t have to do things this way in order to succeed. This particular approach is not the only way to solve a problem or figure out a strategy.

I definitely have taken bits and pieces of everywhere I’ve worked and applied that to what we’re doing here at Kit, in terms of how we work together as a team. Something I took away from Google was that writing things down — writing out your thought process — is just unbelievably basic sounding, but so useful. Figuring out at the top of the document what your objective is, what problem you’re trying to solve, what goal you’re trying to achieve, and how you’re going to measure the success of it, and then writing down what you’re going to do, is a basic and good method of thinking through a problem. That was very consistent at Google and something that I’ve taken to Kit.

Something that I took from Apple would be the emphasis on defining the problem to be solved — as opposed to defining the solution — particularly when it comes to product design. It’s very easy to jump directly to “Oh! We need to build this feature.” It’s so easy to do that — I catch myself on that every single day. Designers do their best work is when they are empowered. I believe the way you empower them is by emphasizing the problem and leaving it to your product people, your designers and your engineers to come up with a solution. Because it could look like anything, something completely different from what you may have in your head.

Tell us more about what got you started with Kit – where did the idea come from?

We started working on Kit in the spring of 2015. It was very much a kernel of an idea at that point. We had a couple problems that we wanted to solve: my cofounder Naveen was coming at it more from a standpoint of a person who likes to share what he’s doing on the Internet. He gets asked a lot about the camera that he uses for the photos he posts, for example, and is just generally someone people go to for recommendations. And he loves platforms.

I came into it more from the consumer standpoint. I had just moved to New York from a year abroad in London, and when I got to London there was so much I didn’t know. I didn’t know where I was and I didn’t know how to get anywhere. The weather is completely different, the light patterns are different. The water is actually different, which makes a difference in the tea you drink, the coffee, the products you put in your hair. It’s the little things you wouldn’t think of ahead of time. I was coming off of this experience of being really reliant on friends, blogs, all people who were more knowledgeable, with more expertise. I had one friend who I reached out to almost every weekend, like “where do I get the best rain boots?” and a blog I went to religiously for other tips.

So, we came together and thought we could really marry those two ideas: on the one hand, someone with expertise sharing what they know, and on the other hand, developing a resource for people who need that expertise to go to and find things that they are looking for.

That was the original kernel of an idea. Then we spent about six months or so prototyping, and talking to our potential target customers. Will, our founding engineer, spent time working on different product search APIs, and trying to figure out how we could quickly iterate. We had a few hypotheses around who would be the first people to create kits. I worked with a lot of creatives during my time at YouTube and iTunes. And my dad’s a musician; I come from a creative family. I had this idea that people who create content, who are makers, who are builders, love sharing what they use because it’s part of their process. I knew they get asked a lot about what they use and what they swear by.

We started off with that hypothesis, and we were kind of searching for the right slice of content creator. Who is that person that would use Kit in its early stage, when it’s still a nascent product? So we built an alpha. We launched it to friends and family, and within two days we sold a two thousand dollar camera from someone’s Kit. We thought, “Huh. There’s something here.” Fast forward to 18 months later: we’ve really found our niche within online content creators who have a following, who communicate to their fans and their followers, who have different specific areas of expertise. One of our creators, a rising star on Kit named Kraig Adams, is on pace to earn a hundred thousand dollars from Kit this year from his affiliate revenue (which he earns a cut of when someone buys a product from one of his kits). And now we’re driving millions of dollars in sales from across the Kit.

You’ve just successfully fundraised, and built a team and a great product. What’s your advice to folks just starting out? What are the very first steps we need to take in terms of gathering the resources to move forward?

If there’s been one point that’s been driven home to me, it’s the importance of focus. It’s really hard to focus. One of the things Steve Jobs said when I worked at Apple (he was still around when I worked there) was that the reason Apple was so good was his ability to say “No.”

It was his job to say “no” when things weren’t good enough, to say “no” when they were working on the wrong thing, to say “no” when the design wasn’t quite right, to say “no” when the copy wasn’t quite right. That was how he viewed his job. It takes an incredible amount of focus to be able to do that.

People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.

And now, working on Kit, I see what he’s saying: it’s the importance of focusing on the right thing. So my advice would be to figure out what you’re optimizing for and optimize for that, and don’t do anything else. Figure out what you need to do first, maybe it’s hire, maybe it’s fundraise, maybe it’s build a product, and do that. And then whatever else is on the list, get to it when it’s time to get to it. But when you try to do five or six or ten things at the same time, I’ve found consistently with a small team that’s resource strapped, you can’t make progress on any one of those things because you’re only accomplishing a small amount of everything.

That’s a basic to-do list technique: look at the big things at the top and do them, and then cross them off and move to the next one. It’s the same concept, but it’s much harder to do when you’re doing something as massive as building a company. The things you need to do are varied, they’re complicated, they’re complex, they’re very hard. Figure out what it is you’re optimizing for and optimize for that. Continue to focus on that at all times.

Can you tell us about how you bring that focus to your processes at Kit? How do you all work?

At the start of every period – say it’s a month or a quarter, whatever our timeline happens to be at that point in time – we set a goal. It will be something like “Okay, this month we’re going to double down on driving this metric,” going back on this theme of picking something to focus on.

Once we’ve gone through the process of figuring out what’s the top-line metric that we want to drive, then we do some work to understand what are the levers that we can pull on to drive that metric forward. We ask, what do we know today? How are things performing? What drivers and levers are at play? And then we do a brainstorm using The KJ Method, and at the end of all of that we’ll come out with a list of priorities. Typically, they’re problems to be solved as opposed to solutions.

Sometimes a couple solutions make their way on the list just because we do talk to our users a lot. We capture and collate every single piece of feedback that we receive from customers, whether it’s in an interview or an email.

I would say this is the first place where the focus comes in. Defining that top line metric and understanding the drivers is tough, because we have a very long roadmap and lots of things we want to build. And this is the first place where we have to say no.

Then we jump into our sprint process. We have what we call “discovery” sprints and development sprints running at the same time. Discovery is the process of problem-definition; understanding better what customers are asking for, doing design exploration, and figuring out technical limitations. We do all of that so that the sprints can be really focused on development and shipping, getting the code out the door.

So design, product, and engineering will work together on the discovery. We’ll do user interviews and some prototypes. We have an environment that we call “Westworld” where we’ll put up iterations of the product that we think will work, and we use real public data on the site so that we can see what it’ll actually look like and play around.

When we feel like things are in a good place, then we get them ready for development.

That whole discovery process can take some time, but we invest in it so that when we ship the thing, we have a higher level of confidence in how it’s going to perform. If we don’t have that confidence, we’ll ship an AB test, which is cool to get real life data. Even after you’ve done all of that upfront work, once a feature is live and you learn something new because people are actually using it… or in some cases not, haha!

It’s definitely a balance between moving quickly and not spending time building things that don’t matter. Again, coming back to focus and saying no, this is another place where it can be challenging. Sometimes we go through the discovery process and we write the A/B test document and realize “Actually if we even ship these features it’s not going to move the metric we care about. So put this on the back burner for later or squash it all together.” That’s a little tough, as a project manager, when you did all of this work and it didn’t see the light of day. But on the flip side, that’s how you ultimately save time and resources, and make the product better.

Once we launch features, send out comms, write a blog post, maybe send our users an an in-app message. That’s when our customers finally get to use and enjoy it.

On a weekly basis in our team weekly meeting, we do a look-back. We’re really big on retrospectives at Kit. When we do our retrospectives, the format is “went well,” “didn’t go well,” and “improvements for next time” (and often we pick a new set of emojis for these each week, ha). This is part of our evaluation process, both for understanding how the product features are performing, and also to ensure we’re working well together and constantly improving.