I shared the below article with my fellow PMs at Sourcegraph on my last day. I find these helpful regardless of field or position and wanted to share it in a more durable way here.
How to be successful as a PM at Sourcegraph (though, these are likely applicable to any role at Sourcegraph):
Your job as a PM is to build momentum. Day to day, you do that by setting clear product requirements to help engineers and designers run fast. But at the end of the day, you should aim to succeed by building something that grows exponentially. This can take on many many different paths but is critical to how I view myself and how I believe great PMs operate. Everything that I outline below builds on this idea.
- Forget about your job description. Sourcegraph is still a very small company 4 pms, less than 50 engineers, and less than 200 people total. Even if we perfectly distributed those 200 people across roles and responsibilities, things would still fall through the cracks. It is your job, as a PM, to make sure you’re filling the biggest gaps, and this will mean doing things not technically on your job description.
- For example, when I was the PM launching Sourcegraph Cloud, I scoped the MVP, onboarded our first 30 SMB customers, was the first line of email support, and helped close the first deals for paid customers. Very little of this was on my JD, but again, my ultimate goal was to create momentum for the product, so stepping in to do anything required helped in many ways. Being the first line of support meant that I saw every bug and feature request from customers. Helping close the first paid deals meant I heard firsthand what features customers would pay for.
- Move uncomfortably fast. You’ll hear Quinn talk about 1 way doors and 2 way doors; study this and master it. Looking back, I often thought doors were 1 way and moved much slower than required. Many of those moments the only thing holding me back was my comfort with the decision. It is widely known in the startup ecosystem that speed is one of a startup’s core advantages vs established incumbents (i.e. Microsoft) and we must live that to win. As I move to start a new role, my aim is to make decisions 25% faster without any degradation in quality, and I hope all of you will challenge yourself to do the same because moving fast does help create momentum when focused in the right area.
- Spend time with users. This feels obvious but must be repeated here. We’re still a small company os unlike Fortune 500’s, PMs here can easily meet with users and customers without running through any red tape. I believe this is critical to building a great product and would encourage you all to spend as much time as possible with customers.
- Make friends across the organization. This might feel obvious but due to our remote nature can be hard to achieve. Spend time to meaningfully get to know each other. Did you know that Erik Seliger comes from a family of woodworkers (back to his great grandparents) and he hand made his dining room table with wood that he found in his grandfather's wood shop? Or that Rob Rhyne spent years traveling around Baja Mexico surfing every chance he could get? The people around you are truly inspiring people and I believe when you open up, everyone benefits.
- Demand greatness. The organization is ready and wants it from you. I was too nice during my time here. Everyone here wants to work with great people and they want to build something great together. I didn’t always demand great from my colleagues as much as I could have. Do this in every single thing you do and your colleagues will.
Things I wish we would have done… These are very specific things that I wish we would have done earlier/better. Hopefully these will help you all as you move forward!
- Pick one way to track work across the org and force teams to follow. Multiple times, we’ve spent ~months trying to figure out the best way to track work across the teams and/or trying to figure out how to build things like burndown charts. All of this pain comes because we want teams to be able to choose how they track their tickets. IMO, this is a distraction. Yes, teams will complain for a short period of time after being ‘forced’ to track work in a single way, but eventually the org will experience the benefit of streamlined process.
- Spend more than 70% of engineering time on differentiation. We’re still a startup, and we’re facing pretty big competition (both in number and size of our competitors). Going forward, we must do a better job of limiting the time spent on non-differentiated experiences. Most ‘blocking’ product features from enterprises are actually not blocking and can be pushed to focus more on what we can uniquely do.
- Ask the really hard questions. A few folks across the org do a great job at posting ‘tension’ documents when tensions exist, but I think we’ve largely lost this culture in favor of DM based processes. Quinn always says he is open as a CEO because “the more eyes on the big problems, the more likely we are to find a solution”. I fundamentally agree with this and hope we get back to this culture of openly discussing big issues.
- Track decisions in a more public, durable way. So many decisions in my time here have been lost to Slack/Google Doc craziness. The solution I have seen work best here, if the team commits, is to track a decision log in a single Google doc that is pinned at the top of a slack channel. I wish all teams would have committed to this and follow through on it. Looking back, it would have made my life 10x easier and helped us move 10x faster.
And with that, my time at Sourcegraph is over! I’m excited to see where you all take it from here!