I became an engineer after a conversation with a farmer. It was a classic 28°C day in December 2009 on Maui, Hawaii where I was picking weeds and moving cockroaches from garden to garden. My friends had graduated high school and were off at university while I was working seasonal jobs and “taking it easy” during the winter. At lunch, farmer Marilyn said (something along the lines of), “sometimes we don’t know where we’ll end up but we at least have to start the journey”. Cliché, yes, but for whatever reason, it stuck with me. After returning home in the spring, I set out to attend a bootcamp-like design school. The problem was, as I neared the end of my schooling, I realized I was a terrible designer.
One of my first interviews for a junior development position was 4 hours long. I loved it. Looking back, signing on to a brand new 5-person company as a junior developer straight out of school was an absurd idea but I think it fits my outspoken personality. I find a lot of people don’t speak up when they see something they disagree with and I was happy the first company I joined allowed me to say “no” as someone without experience.
Now that I’ve grown through different teams I realize having the confidence to go against the grain, as well as creating an environment where this is acceptable, is something all teams should be conscious of and work toward. This helped my transition from developer to product manager because you will get feature and change requests from every angle at every meeting and you must manage expectations. Your team will look to you for direction and if your plan is changing day-to-day or even week-to-week, you’ll hear about it during retrospectives.
All the questions I had about my new role
Do you miss being a developer?
Being a software developer isn’t all it’s cracked up to be - for me, anyway. I became a product manager because I was interested in how “the other side” of the business worked, but there is also a different pace to this side. For instance, the thing I miss most about development: microdoses of happiness when completing tasks. The same way you see the heart icon popup when logging into Twitter or Instagram, seeing the purple “Merged” badge or the green “Approved” checkmark gave me the same feeling. The feedback cycle when you’re on “the other side” is definitely slower though oddly more impactful after delivery. With that said, if I had to have another discussion about rebasing vs merging, single vs double quotes or linting configs, I think I would have gone back to farming.
How is your life now?
As a developer, I hated meetings. “I just want to code” is the motto of 87% of developers (made up statistic). Product managers don’t have the same luxury. Well, I suppose it’s less about meetings and more about communication. I quickly realized if anyone - or any department - is out of sync with the rest of the team, it’s probably going to fall on my head. If you haven’t made the jump to product management but are thinking about it, you will not get away with being able to “code in a corner” and hope no one notices you.
Another aspect I feel is important (and one I need to improve on) is being a good storyteller. From getting buy-in from the team to interactions with customers to presentations with stakeholders, everyone wants to have confidence we’re building the right product. What is interesting and exciting about a new feature for a designer? How does this improve the experience for your users over their other feature requests? Why should the CEO trust you with $500k worth of resources? These aren’t stories that need to be told once and forgotten but recited regularly. Make your team understand why you believe this is the best direction. Go wild, get a little cultish, preach!
Is it a force or a weakness to be a former developer?
It is completely understandable engineers transition into product roles since engineers understand how to build software and software is (most likely) the product. On the other hand, once you’ve made the transition, keep your mouth shut during product and design meetings - I’m kidding (but not really). When someone asks, “how long will this take to build?” or “how technically feasible is this?” be cautious in your answer because you’re now walking the fine line of stepping on developer toes. You don’t get to speak for the development team in terms of effort anymore - at least not until they have explicitly agreed on it themselves. Where I do find myself valuable is being the person who ends up saying, “this is more complicated because of x, y, and z” which comes back to the “speak up for yourself (and your team)” lecture.
What is your biggest challenge?
The tough part of product management: there is definitely no way to do it correctly. There are a hundred different ways to track goals, there are a hundred different ways to define an MVP (or an MLP, or an MMP, or whatever else we’re calling it these days), there are a hundred different ways to run processes and handoffs and communication, etc. I was fortunate to have a great mentor who provided a framework for how we would run our product process but if you don’t, I suggest looking up a few product frameworks from other teams and copy it. If some parts of the framework don’t apply to the makeup of your team, change it! There is no right way other than to try new things and iterate with what makes sense for you and your team.
The tough part about product management (coming from development): the difference in problem-solving. When programming, if you write a function to find the sum of two numbers and then call the function with two numbers, you get the sum of those two numbers (wow!). For the most part, it’s straightforward and the validation of what to build has been done. As a product manager, when your doing research for a new feature and customers are asking to be able to drag items up and down in a list, their underlying need may not be to move the items but rather group them together. Both features (moving vs grouping) will be useful to achieve their result but, depending on which feature you choose to build, will change the direction of your product.
Do you have ONE advice for a developer wanting to become a Product Manager?
If I had one takeaway from my transition it would be to learn how to prioritize (if I was allowed two, I would include communication but I’m on a short leash). In my first week as a product manager, I had a list of 50 things I wanted to fix. I got through maybe 4 of them. If you stopped all development at your company, how long would it take to fix every known bug? 1 year? 2 years? 5 years? The sooner you take a deep breath and realize everything can’t be DEFCON 1, the quicker you’ll have a clear mind for your true priorities. Trust me on this one: everything will be okay - even if you’re still receiving hate mail (unless you’re receiving exceptionally more hate mail than you usually do, in which case, yeah, maybe something is broken).
There is an incredible balancing act you have to put on between customer needs, technical debt, sales and marketing requests, design changes, business priorities, and so on. Ask yourself: fixing small user experience debt feels great (again, coming back to fast feedback as an engineer) but will it move the business forward? It’s easy to constantly fix the small things; it’s hard to say “no” in order to achieve a greater goal. This is by far the toughest part for me because we end up saying “no” to a lot of great ideas - whether it doesn’t fit into our product direction or the timing isn’t right. Prioritize your customer needs while adding value to the product and, ultimately, the business.
Thanks for reading! You can reach me out on Twitter if you want to discuss anything project management related.