Learning a new space
Before Dark, I worked on two consumer products, and experimented with many more. Over these jobs I ramped up on three distinct product spaces: productivity tools, crowdfunding, and travel. Each one had a learning phase followed by an execution phase.
When Paul and I decided to start Dark, I was thrust back into a learning cycle. There was still some overlap with what I’d done, but I needed to ramp up incredibly quickly on what it meant to be a devtools company.¹ Some people like to stay in one space and build experience that way. It’s helpful that Paul has done developer tools before. That said, I think there’s also value in people moving between spaces to share lessons. I like to be that person.
Here’s how I recommend ramping up on something completely new:
Remember what you are good at.
We’re all human. It is daunting to walk into a room feeling like you’re the novice (especially if you’d gotten used to being the expert at something else).
To get through a steep learning cycle, it helps to remember what you’ve already learned. I started Dark knowing that I knew about great consumer experiences, marketplaces, and how to build and manage a team. I also knew I was good at learning and the pain would only last so long.
To get myself through it, I didn’t eliminate what I did before. The key is to do it just enough to keep your emotions up. I finished my PM book. I continued to take 1–2 meetings per week with aspiring PMs and Heads of Product. It helped me feel competent, and I could see how my perspectives changed as I learned more about the new space.
Build initial scaffolding.
At the beginning of learning a new space, you’ll know nothing. You have to figure out a scaffold that you build on top of. The best way to get started is to learn the basics so you’ll know what you don’t know. Here’s are some good ways to do that:
- Read books. I love this as a starting place. It’s a good way to get an overview, and I’ve met a lot of other founders who do it. (Drew Houston has referenced High Output Management and The Effective Executive as starting points to learn about management).
- Go to a conference. As I started thinking about React as an ecosystem, I went to the Fundamentals day of the Reactathon conference.
- Talk to a close friend. Talk to a trusted friend in the space. When I started in travel, Ethan was a huge help. When I started in devtools, Paul and I spent hours on the phone where I asked every question I could think of before we decided to work together.
- Go down the internet rabbit hole. Some mix of blogs, newsletters, and just following the right people on Twitter can help get your map started (I like to do this later, but to each their own).
Meet people, level set, and ask tons of questions.
As soon as you get the basics, it helps to start asking people to help you fill in the details. I’m incredibly grateful to all the people who talked to me at the beginning of Dark (including, but not limited to Tom, Steven, Molly, Noah, and Meagan).
It will never get easier to admit that you don’t know things. These conversations are not a chance to “fake it until you make it.”
Be honest and upfront that you’re getting started. At the beginning, you can say “hey, I know you’re an expert at this space. I’d love to learn more about X from you.” Sometimes I told people I was already overwhelmed and needed help sifting through my troves of information.
Then ask all the questions you want to ask (even if they sound dumb). Write down the answers. Keep asking people, keep writing down the answers. This part can be scary. At one point someone said to me:
“Why’d you decide to start a company in a space that you know nothing about?”
That burns. But, you’re never going to know if you don’t ask the questions. There’s no shame in not knowing (yet). There is shame in not trying to learn.
Try things out.
A lot of people will start here, but knowing what to try means you already have some baseline knowledge. I like to get an idea of the space and what I’m trying to learn. Then I compile a list of everything I want to try.
When I was at Lola, this meant staying at lots of hotels. I would usually stay at Airbnbs, so I started planning trips to experience different hotels (and opting to stay at hotels when I had conferences).
In devtools, I was curious about tools that were meant to accelerate development time. I was interested in frameworks. I spent a while running through the Meteor Todo tutorial. Over time I shifted my focus towards React and Vue. Devtools is a space where building lots of project helps.
Update your scaffolding.
After you’ve spent time researching, having conversations, and trying things, you’ll likely have an updated scaffold. This will help you see where to go to next.
Most importantly, you’ll start to get a feeling for who is interesting in a space. This includes the people who are always pushing the boundaries of what’s possible, and the people who define the community. Follow these people on Twitter, read their newsletters, and pay attention. This will be how you know what’s coming next and prevent your knowledge from going out of date. Industries are built by people.
You’ll start to have a feeling for what’s interesting to you and why. That might mean more research on sales cycles, and it might mean more research on how to use Redux to manage component state.
Repeat as necessary.
Once you have an updated scaffold, you can repeat the process with minor tweaks. You’re no longer a pure novice, you’re just a novice in an area (and maybe not even that).
You might only need to do one of the processes — if you’re interested in Redux, building something is probably faster than talking to everyone about the future of Redux. Similarly, you can go to one conference (or read a bunch of documentation) and then decide that you don’t want to build using that technology.
It doesn’t matter that you do each step. Each step will help you learn in it’s own way. You can (and IMHO should) keep doing pieces of this forever to continue to grow in a space.
Apply your own lens & execute.
At some point, things will stop feeling so overwhelming. It will no longer feel like your brain is oozing information about the new space at an alarming rate. There will be some steady baseline even if you aren’t an expert. This is when it starts to be fun to bring back all the skills you built in other spaces and execute.
One thing I’ve noticed about devtools (and especially in programming languages) is that the products are designed for experts. There’s an entire canon around what makes for good onboarding, including documentation, tutorials, sample applications, and demos. Even reading the help is a steep learning curve for trying something new. This is very different from consumer. A consumer product with that ramp up curve would have extremely low conversion. Consumer products very rarely require lessons, and the next step should always be obvious. You learn by doing.
It would be difficult to make a developer tool as seamless as a consumer product, but my background in consumer leads me to believe that our bar for usability in devtools is still too low. At Dark, we develop our product with users. We showed 90 engineers our product in the last quarter, and we have a full time customer working with us to continually improve. We think it should be orders of magnitude easier to write software, and we’re going to do that.
¹ If you’re curious… Devtools has some characteristics of consumer products, some characteristics of b2b products, and some characteristics that are unique to developer products. HeavyBit is an incubator devoted exclusively to devtools companies and a great way to learn more about devtools in particular.