Q&A with Jager McConnell, CEO at Crunchbase
#Topic: Scaling Products
I was wondering how to build a social network of companies. Then Crunchbase came by, and they were a network of companies that were being funded and used. But they didn’t have a CEO and had little vision. As a product guy, it was a dream come true, because I was handed a company that was already down the line of the vision that I wanted. I joined Salesforce to pump my resume, but it turned out to be a good career move because I learned a fair bit.
- Spun out as an independent company in 2015
- Launch first paid product in 2016
- Kept Crunchbase free but made paid supplementary features.
- Trying to become the master record of companies on the internet
- Grew from 20 people to 60 people today (90 by EOY)
- Recurring revenue has grown 20x
- Raised an $18M series b in early 2017
- 39 million people globally use Crunchbase, although very few of them are paying for it.
- Data volume growing at an exponential rate.
When I came into Crunchbase, I killed a lot of features and projects that weren’t aligned with our vision. We focused on Crunchbase pro, and a prospect tool and focus on nothing but that. Not focusing on your visions and creating natural extensions of your product can sometimes feel like the right thing to do. What it leads to, is stretching yourself too thin. Focusing on your product allows you to successfully make iterations. You need product leadership on your team. A CEO cannot be the head of product. Your product needs specialized direction.
- Keep focus
- Start hiring your head of product yesterday
- Think about your support costs as your expand footprint
- Don’t drown in tech debt by building your house on sand
- Stop building monoliths
- Kill features
- Don’t compare yourself to anyone, ever
For example, Salesforce and Crunchbase took a 6 month hiatus from building products, and features because they needed to re-platform in order to build iterations. So avoid building monolithic features. Try incremental features and iterations. You should also continuously align yourself to product market fit. The market is constantly evolving and you need to evolve with it. So if the new features don’t create the engagement you need, then you need to kill it and focus on the things that do. Even if it pisses users off (Disclaimer: if your users pay a million dollars a year subscription vs a $350 a year subscription then you really can’t afford to piss your users off).
Sometimes Crunchbase gets called the Linkedin of companies. This is helpful if you want to convince your investors to invest, but it isn’t when you’re trying to convince an engineer to build a feature, because he’ll say “bring me an engineering team Linkedin has and I will gladly make you that feature”.
Key Question 1
Can your scalable product tips be applied to scaling operations?
Well, the AGILE model was applicable for everything at salesforce. We have the same “lean startup” approach to everything.
Our in-house approach:
I Ideate — come up with a hypothesis of your task
T Test — Build that thing
L Learn — learn from the results
I Iterate — Iterate so that means if it doesn’t work, kill it and start over.
Teams are created around projects. So a marketing person and project person are stuck together, and there is good synergy.
Key Question 2
Do you have any ideas on how to go about doing this?
So what we do at crunchbase is mostly web based, so we don’t have to make multiple versions. When we did make individual apps for clients, we decided to outsource integration. A lot of our customers had tech teams that did the integrations themselves.
Key Questions 3
When you mentioned you killed a lot of projects when you entered, how long did it take to make that decision, and how did you convince people this was a good idea?
There was a lot of friction at the beginning. I knew going in, I was going to kill a lot, so I went in with the mindset of “what’s worth saving?” It took 6 months to unwind everything that was in flight. Some engineers were so passionate about their projects, they told me it would take a few weeks to unbuild, when it didn’t. I was trying to manage the situation, but in hindsight, I should have followed my instinct. Most projects were killed in a month, but the rest took 6 months.
Key Question 4
How do you protect the teams so that they can deliver quality work, without CEO’s, shareholders and investors coming up with new ideas that end up slashing departments?
Salesforces is notoriously bad at this issue. The CEO would kill entire departments because of the thought he had that morning. I don’t know how to navigate that position from the bottom up, but I would remind them what the goals and visions are, and is that really representative of the company.
From a bottoms up perspective, you need to address your concerns and make the following case: I will not be able to pick up where I left off, and I will probably have to restart a few things and if we ever get back this again, there will be double the work. So is this thing as critical to our company vision as the other thing? And if it is, then I want you to openly acknowledge that and we both have to agree on that.
Key Questions 5
When you are trying to integrate into an existing industry, and when you are trying to navigate the process between two parties such as labs and doctors on a platform, how do you do it without going crazy? And looking for a better market fit more efficiently. How can you get analytics and feedback to find out if things are well received or not? We don’t have the luxury of feedback from 30 million users.
If they’re both paying parts of the equation, its hard and there is no silver bullet. We use a bullseye user, which is like a layer cake of stakeholders and the middle is who we care about. We care about entrepreneurs and sales people, and we build for them. One of them is a priority. Second is the people that are integral to the process: stakeholders. The last are people you don’t care about: students or people looking for jobs.
So for feedback, it all depends on scale. If there are 10 users, then the CEO has to have a personal relationship with all of them. But if it gets larger then you need CSM’s (Customer Success Managers) who would talk to the clients and users with a lightweight touch and provide feedback. If you get too big then you need an MPS (acronym unspecified) and try and give people incentives for giving you feedback.
Key Questions 5
When you scale and end up with large engineering teams, there are times you need to feed the beast and not keep the engineering team idle. We have had pressure to keep them occupied. How have you handled that?
As a product manager, you have to make sure that is never the case. You need to map out so much more into the future to achieve this vision. You need to also do this a quarter or 2 in advance of the engineering team.
How do you make sure your technical team doesn’t suffer a setback?
Your Engineering team lead needs to be on the same track as you, and very passionate about the direction. At Crunchbase, we have a methodology of building platform first. It does put restraints on the tech, because you can’t do anything too crazy or special. But it also means, there isn’t a place on the tech that is a special snowflake, and only Jimmy knows how to make, and when he’s gone in 6 months, nobody knows how to make it, and it’s confusing. Everything is API first.
Also, make sure you choose the architecture that can allows you to scale to your business. I’m anti ruby on rails, or any single monolithic app where everything is intertwined into one gigantic code base. That’s what I mean about building your house on sand. So you make a decision early and avoid tech debt and not complain about scaling failure.
Key Question 6
How do you manage small vs large goals for your product?
I like putting all the features together and getting the t-shirt size or prerequisites. But there needs to be a blend between the 2. Everyone likes the quick wins, because everyone wants to feel like they’re winning. Even the customers like it, because they feel like there’s iteration happening. If you make a slow and fast lane, then you will find the fast lane may be too fast. The small wins are the engineers happy sauce, and so there needs to be a balance between the 2.
Key Questions 7
Do you see a difference between a product owner and a product manager?
Don’t use product owners, everyone should feel like they own the product. Engineers need to feel valuable and not just tilling the fields.
Any best practices for moving into AGILE methodology?
Make sure there is buy in to make transitions successful.
How do you make sure the vision of the product translates to day to day activities?
Vision, Value, Methods, Obstacles, Measures or the V2MOM method. All departments, functions and people did this and it was consolidated. Then use the OKR to track things to the metric.
Key Question 8
To Avoid technical debt, how do you ascribe value to your vision, as opposed to the generic value of more features?
Learn to make sure your software architecture is scalable, but also ask yourself whether this is true to your vision. You could be wrong if you attempt to intuit the features you think your customers want.