What is Product Management ?! Part 3
An Interview with Joe Kendall, Product Manager at IBM
Are you thinking about a career in Product Management but don’t really know what being a “PM” means? I was in the same boat, so I interviewed some of the top industry leaders like Joe Kendall, Product Manager at IBM, on their journeys and advice for people just starting out. Below are Joe’s very helpful and candid responses, which I hope helps others to break into PM! To chime in with thoughts or read other interviews, scroll below. :) -Niki
1. When did you decide you wanted to be a PM, and what specific things led you to that decision? Tell us your story. :)
From what I can tell, almost every PM has a pretty unique background. My own starts by studying mechanical engineering and working as an engineer building speakers. In hardware, there’s not typically a PM role like there is in software; people usually have a specific specialty (materials analysis, power electronics, etc), and I was no different.
As I worked as a mechanical engineer, I was naturally drawn to question what value we were adding through our work. I also went out of my way to understand how all the parts fit together into the larger system.
I realized an elegant engineering solution is awesome, but elegant engineering is useless if it doesn’t help the end-users, is not cost-effective, or can’t be sold.
So how did I decide I wanted to become a PM? I didn’t. I sort of fell into it by constantly looking at the larger systems while thinking about the business and usability impacts of our engineering decisions. This information usually gave me a point-of-view, and I’d collect supporting information and advocate for that point-of-view with peers and corporate leadership.
Eventually, consolidating information around a POV became a standard part of my role and I became the point person for individual products. Although I still had a role as a mechanical engineer, I spent more of my time balancing design, engineering, and business requirements and tradeoffs, and then leading teams to implement the solutions. By following my personal passions for systems thinking and collaborating with others, I’d inadvertently turned myself into a tech-industry-style product manager in hardware companies.
Being a software product manager isn’t much different — the language and tools of a hardware startup are pretty similar to the language and tools for agile software development. In many ways, it’s easier in software because distributing products and soliciting feedback are both easier thanks to the Web.
2. What does your day-to-day look like?
My day-to-day is broken up into about 4 different categories, which vary depending on where we are in a sprint / when and how big the last fire drill was. My entire team is geographically distributed across the country (and sometimes globe), so I spent a lot of time on Zoom.us web conferences.
In a given 8 or 9 hour day, I spend 2–3 hours in meetings aligning with other PMs and leadership in my organization whom I have dependencies on or who have dependencies on me. These conversations are usually around clarifying alignment and finding the right way to translate strategic goals into tactical direction.
About 2 hours are more informal conversations and check-ins with members of my team or other dependency teams. These conversations are typically about identifying and removing any blockers, with some prioritization conversations as well. We also have a daily 15 minute scrum mid-day to review status, and there’s usually a couple follow up conversations that come out of those.
The remaining time typically is spent doing market research on competitors, testing our current/in-process iterations, or synthesizing information into reports or decks (usually for a particular stakeholder/set of stakeholders). Most days I only have time for one or two of these tasks.
Lunch is usually a chance to catch up with colleagues or collaborate on a side project in the design studio where I sit.
That said, some days (like when running workshops or release days) are completely different. The variability is one of the things that makes this job so interesting.
3. What’s a specific challenge you’ve had in PM and how did you overcome it?
My largest challenge as a PM has been transitioning from hardware to software.
Coming from hardware, the perception is that you have no knowledge or awareness of software development, and that’s a tough thing to overcome.
I found it was easiest to approach it like any new field or industry: make it clear you want to learn, and ask those around you to teach you. For me, getting my colleague’s help while trying to build a simple chatbot or mockup a user-flow was a great way to build empathy and respect for the field and each other.
4. What is consistent in PM with every company you have worked for? What’s different?
My experiences at small (10–40 person) hardware startups were very different than my current role at a 400,000 person IT legend. What’s been consistent is the need to be constantly seeking out, collecting, and sharing information about the different workstreams happening at any point in time. And in every company, whatever I was doing, I was there to serve the product and the rest of the product team.
Beyond that, they’re pretty different.
In a small company, I had easy access to any internal information and could take action quickly. I also was responsible for everything from producing marketing demos and writing copy to designing analytical tests and reporting outcomes on KPIs and generating new business.
In my current role at a large company, I spend much less time directly doing work supporting the product and more time defining the bounds of our solution space and communicating dependencies and a point-of-view to all the different leaders in my org and others.
5. What does a senior PM do that a junior one might not?
As I see it, a senior PM finds an opportunity, while a junior PM is given a problem. Senior PMs are responsible for identifying and building a coalition to address an opportunity. Junior PMs are usually handed a known problem and told to fix it. There are differences in level of responsibility, degree of handholding/scaffolding, and scope of problem. But the primary distinction I’ve discovered is that self-direction and capacity to build coalitions.
6. What things have you done in your career as a PM that has really helped you level up?
Being patient and trying to build empathy with those around me has been more helpful than anything else I’ve done. Lots of people talk about raw intellectual horsepower and innate curiosity in PMs, but those aren’t really conducive to most collaborative environments. Just because it seems obvious or clear to you doesn’t mean it is to everyone else. Explicitly taking the time to see a problem from someone else’s perspective, and then including them in the decision process has become the best tool I have to improve the outcome for everyone involved.
7. How might a PM role at a startup be different from a PM role at a large company?
See answer #4 for a longer answer. Short answer:
In a startup, you do a bit of everything. In fact, you do whatever needs to be done to keep the product and company moving forward.
In a large company, you have a narrow scope, and you spend most of your time aligning with all the other teams.
8. Who do you collaborate with most on a daily basis? What usually brings about successful collaboration?
I spend most of my time communicating with stakeholders and other PMs. I wish I spent more time collaborating with more designers and engineers (as I used to at smaller companies). What I’ve found is the most successful collaboration comes from a ‘three-in-a-box’ model: a design lead, an engineering lead, and a PM lead. Having a close-knit product leadership team where everyone respects each other to be the expert in their own discipline is crucial for effective collaboration.
9. What words of wisdom might you give yourself 5 years ago? And what advice would you give to people just starting out in PM?
Five years ago, I would probably tell myself to trust the advice I was getting from my grandfather (which is summarized below).
1) You are hired to fill a specific need, but that is not your full job description. Do what you’re paid for and define your own role by doing what you’re good at.
2) Figure out how the company makes money and focus on that area.
3) Ask questions. Meet Customers. Collect all the data you can, both quantitative and qualitative.
4) Crisis equals opportunity: work on the big messes because it’s a chance to solve the biggest problems.
5) Learn how to communicate in business: presenting succinct, complete ideas is most important.
And I’d add one more:
6) Solicit feedback constantly. You can only get better by understanding your own strengths and weaknesses. Plus, being humble enough to know that and ask your peers for feedback will improve everything across the board.
10. How did you find your current job, and what was the job-hunting process like for you?
I found my current job through conversations with the GM of IBM Design. I was looking for a way to apply design thinking in product management, and that was a personal passion of his. As he was out recruiting, we began talking and that conversation led to more.
In fact, all my PM roles have come from one interesting conversation leading to another.
11. What major were you in college; how has that helped or not helped?
I majored in Mechanical Engineering, and then got a Masters in Engineering: Product Design. I think both degrees helped me learn to think in systems, but neither has helped me explicitly find a job in software product management.
12. What skillsets do you think you are gaining and in what other positions or industries might they apply?
I think I’m gaining a lot of communication and analysis skills that will help me in almost any industry.
13. Anything else you would like people to know about PM?
There are lots of people who want to be PMs and think it is a good fit for them because they love tech, are not coders and/or want to be the next Steve Jobs. I think it’s a great fit for many people, but in some cases has been over-hyped. The most telling thing to me is to recognize for yourself how much you want to be in service of others. A good PM is working for the people making and the people using the product, which means they are almost never working for themselves. And they will never have any real control — at best, they will have influence. As PM, you are the person who has to deal with the most bullshit. If these things sound like fun, then PM is probably a great fit. If you just want to make stuff, then PM may not be the best place for you.
Joe Kendall is a Stanford-trained designer, engineer and product manager who has developed products for everyone from Fortune 100 companies to early-stage startups. He specializes in inventing solutions that integrate technology, sustainability, and design into systems which benefit people’s daily lives.
He loves swapping stories and experiences. Get in touch with him on Twitter at @jkendall or through jkendall.net
Niki Agrawal is a tech enthusiast transitioning into product and was curious about what PMs really do, so she interviewed some of the best industry leaders (see other interviews here and here), and is sharing that knowledge on Medium! She’s always down to get coffee with interesting people, so feel free to get in touch at nikiagra1@gmail.com or @nikiagra (DMs open!), or chime in with questions/advice on product management for her and Joe below. :)
