Between starting my own companies and helping to scale Github, I realized that I could have more impact in product than as an engineer.
When my company, Easel, was acquired by GitHub, I began a journey from engineering into product. That transformation culminated in the launch of GitHub Enterprise 2.0 where I started as part of the core engineering team and transition fully to product management by the end.
My experience founding both Flagr and Easel, working as an early employee at Typekit and Adroll, and joining GitHub have taught me a great deal about being a product manager (PM) and how best to scale product.
My experience transitioning from engineering to product
I strongly believe that engineers who are interested in increasing their impact should consider a transition into product. There are many great ways to grow in engineering as an individual contributor, but if impact is something that motivates you, transitioning into product might be worth considering.
Engineers who transition into product bring a unique value to the role, and it’s not solely through their experience of writing code. At its core, engineering is about understanding problems, breaking them down, and then solving them. That same expertise applies to product management.
Deeply understanding problems and then breaking them down is the bread and butter of product management. As a result, an individual product manager can often have a greater impact than an individual engineer, since the scope of the problems is generally larger.
It’s a common misconception that, if it’s crunch time, you’ll be writing code to help your team over the finish line. In my experience that’s a red flag that something has gone wrong with the project and it undermines trust with the teams you work with: If a PM is writing code, they’re doing it wrong.
That said, I still firmly believe it’s valuable to be an engineer, as it gives you a skill set to analyze problems systematically. As an example, a key responsibility of product managers is to receive feedback from different stakeholders. If you aren’t able to create effective systems for gathering and analyzing that feedback, you’ll struggle to develop a comprehensive strategy.
Why you need management
Before diving into product management specifically, it’s worth talking about the general concept. Management often gets a bad rap, especially in tech companies. Many young startups assume that all management is bad, thinking management = bureaucracy = restrictions. I disagree.
While bad management is bad, good management can unleash the unrealized potential in your teams. In my experience, good management can set clear expectations, holds people accountable, and then helps their teams achieve their goals. If your management isn’t doing those things, then there’s probably room to improve.
When I joined GitHub, the company was around 200 people with a famously minimal management structure. It’s taken us some time, but GitHub now has a more traditional management structure, which has been critical in allowing the company to grow. Many of the people that I work with are happier due to this change, but, as with anything that’s a work in progress, there’s always room for improvement.
Another important thing I learned: getting better requires honest feedback and accountability.
It’s hard to give direct feedback to managers because employees often don’t feel safe. It requires a trusting, safe environment.
At GitHub, we use a 360 feedback process that enables people to give anonymous feedback to their managers. It’s been really helpful, allowing managers to get the feedback they need and allowing employees the opportunity to be honest.
Why you need product management
As we rebuilt GitHub Enterprise from the ground up, it became clear that engineering was only one component. Success required a coordination of go-to-market activities such as:
- Sales enablement, so that the sales team knew what improvements were being made.
- Marketing collateral, so that all of our content was technically correct.
- Reviewing customer conversations, to understand the needs of the field.
Shipping software isn’t just about writing bits and getting it out the door. All these elements must combine to form a successful launch.
When I joined, product was an unproven discipline at GitHub and many were skeptical. A large part of ensuring the success of product at GitHub was demonstrating the value of having a product team. By delivering product launches with a coordinated go-to-market strategy, incorporating customer feedback, and preparing a field team, you can dramatically increase your impact – and that’s hard to ignore.
Product managers act as product owners
A good product manager sits between engineering and product, making sure engineering is on target, validated with the customer, packaged correctly, and then delivered to market.
One way to think of product managers is a person holding many ropes:
A good PM knows when one rope is pulled too far in one direction. They re-center the whole product so every group gets the attention they need.
The main task of a product manager is akin to assembling the priorities and feedback of all the different stakeholders into a centralized list. The executive team provides the company’s direction, then the product manager assesses the list through that lens to determine what to prioritize.
Conflict is good. People have a misguided notion that you want a conflict-free relationship between product and other groups. I actually think a more healthy relationship has tension. It’s like a tug of war, where the rope should be taut, not slack. If the rope is slack, something is usually wrong.
No product manager is perfect. With all these ropes, the product manager is often pulled in one way or another. A high-functioning product manager is either minimally biased — or self-aware of their biases — in order to mitigate them.
At various times at GitHub, I’ve found myself too close to engineering. I’ve had sales come to me and say, “It feels like product and engineering are just working on their priorities, while we’re out in the field, unable to convince the customer.”
At this point, a product manager has to say, “Let’s pull away from technical debt. While these are important features, the sales team’s needs are more important right now. They’re on a quota. Their pay is determined by their sales. If we don’t prioritize their needs, it impacts their lives.”
Looking back, I know there are some areas I should have paid more attention to. It’s easy to see in hindsight, but hard in the moment. It requires continual awareness of which ropes are taut and which are slack.
Build your product team when the founders are needed elsewhere
Many early-stage founders wonder about the right time to bring on their first product manager and start building a product team. It’s an extremely important decision that needs to be handled properly.
As a company scales, the founders’ needs change. They need to concern themselves with fundraising, strategic vision, and executive functions. They can’t focus on product forever, so they’ll eventually need to hire someone.
Finding the right time is tough. Product management is a relatively new discipline, popularized some time in the last 20 years. We’re still figuring out when and how to best use product managers, and I feel like we’re over-indexing a bit. I’ve seen some very early startups with literally 4 or 5 people and a Head of Product. Having been a founder, I think that’s too early.
Hire a complementary product leader
Hiring for product leadership typically works out either very well or very poorly.
Founders generally start a company because they’re passionate about solving a problem. Giving up product is difficult because the founder is placing trust in a person to steer the company into which they’ve poured their heart and soul. It works out really well if the Head of Product aligns with the founders, and generally leads to large disagreements if they don’t. If the disagreement is large enough, generally the company and the product person have to part ways.
Generally, there are two types of product leaders: detail-oriented or visionary.
As a founder, you need to hire the type complementary to yourself. If you’re a visionary, and you bring in a visionary, the odds are low that you’ll have the exact same vision. If you have the vision, you need to hire someone who’s detail-oriented and has the ability to execute.
I’ve also met founders who are the opposite: They love the problem and just care about the details. They need to hire someone to figure out the bigger picture. This, of course, requires self-awareness. As a founder, you need to understand how you think about product.
Qualities I look for when hiring a product manager
Once you have a Head of Product, you’ll eventually need to build a team around them. Bringing on the right people is crucial — I look for 3 qualities when hiring a PM:
- Can they sell an idea?
- Can they write persuasively?
- Can they get things done?
A PM’s chief currency is convincing people. You have to sell a vision and articulate why this strategy is the best approach. If you can’t convince people, you can’t affect change in an organization.
Writing is a multiplier on your time. If you can write once and distribute it to 10 people, you don’t have to have the same conversation ten times. Whether it’s an email, a presentation, a GitHub issue, or a Jira issue, writing convincingly is incredibly important.
Getting things done
You could also call this “hustle” or “entrepreneurship.” At the end of the day, product managers are the catalysts for change. They’re driving towards the next hill. They bring the team with them. They have to be able to make things happen.
Why I love being a product manager
For me, programming was always a tool to deliver the experience I wanted. Eventually, I realized the experience is what I ultimately value. I find being a product manager rewarding because it allows me to focus on that part. It’s what gets me out of bed in the morning. Solving problems makes an impact on the world, and I think being a product manager is the best way to accomplish that.
Coming from an engineering mindset, you can have the rigor, understand the specific requests, and dig into hard problems. I’d encourage engineers who really care about the outcome of their work to consider product management as a possible career track.
Photo courtesy of freeCodeCamp.org.