A few years back, I was giving one of the best Product Managers on my team their annual performance review. They were doing a stellar job on the basics but were not yet at the point we could promote them. I thought a lot about why and wrote something about how improving their business acumen would take their work to the next level.

When I delivered the performance review, the PM rightly asked me to explain what I meant by business acumen and provide some examples. This post summarizes my answer.

Business acumen is a critical element for success for PMs, but one that needs to be better understood and is often vaguely communicated. In this post, I'll explore what it means, how to develop it, and why it's crucial for PMs in today's competitive business landscape.

What is business acumen?

Let's start with the acumen part — the ability to make good decisions in a particular domain. In the PM context, business acumen means making decisions and building plans that grow and strengthen the business through its products.

This is a fancy way of getting to the bottom line: business acumen in a PM means you intentionally and consistently design and build products that will sell.

What does business acumen look like?

Business acumen has two distinct but interrelated flavors.

The first is a broad understanding of how business works. This is higher-level stuff like understanding what marketing and sales do, the tools they use and how they are incentivized, understanding financial statements, and knowing how markets and fundraising work.

The second is the consistent application of business principles to your product work. Think about the cost of developing a feature, how it could drive retention or revenue, how it relates to market trends, and the bigger story you can tell when it's launched.

Why must a PM read a financial statement or develop a communication strategy?

You probably won't, at least not often.

But it would help if you understood those things to function at a high level in the role.

"Cross-functional" work doesn't mean collaborating with design, engineering, and PMs on a different team. It means working with everyone to make the products you're building successful when they get to market. If you can start from a place of thinking through at least the high-level implications of what you're building in their world, your launches are more likely to be successful.

Management's easily convinced to fund projects with cross-functional buy-in, which is critical when you're asking for a significant investment or the ok to move forward with something that might create challenges for your customers. If you have the understanding, you can build that relationship.

The other nice bonus is that you start seeing challenges before they happen. Early in my PM career, one of my big projects nearly fell apart because I hadn't factored in billing implications. After working with our finance team to get the launch back on track, I understood their work much better. I started incorporating the billing and upsell implications into my requirements, which made my PRDs better, and the team faster at implementing them because we didn't run into last-minute billing "gotchas."

The final benefit of business acumen is that it helps you put your product into management's context and increases your chances of approval. For example, if your company's computing costs have been very high, proposing a new AI feature will go more smoothly if you can model a compelling revenue increase or find a cost reduction by phasing out a computationally expensive, underused feature elsewhere in the product.

How do you build business acumen?

The answer isn't "get an MBA"! I have an MBA, and it's been an excellent foundation for working cross-functionally, but I still learned a lot on the job. I wrote more about MBAs and how they apply to PM here.

What does it mean to get feedback that you should work on your business acumen? When I've given this feedback to candidates and reports, it generally means they're solid on product development, including understanding their users. However, I need to hear considerations for the broader implications of their work on the business or the business context they are working in.

These five steps will get you started in building your business acumen:

1. Know how your company makes money. What are the primary sources of revenue? What are the opportunities? Is it profitable yet?
2. Understand your company's costs. What are the main drivers? Have they changed recently? (This is where being able to read financial statements helps a lot!)
3. Research the channels your company uses to sell so you can consider the market as a whole. What are their pros and cons, and what customers are they reaching?
4. Identify the metrics and incentives other departments use so you can consider how products can help move the needle for them. How does the sales team define success each quarter? What are some significant marketing milestones? How is the customer support team incentivized?
5. Understand your customers who are not users. You might know what your users need, but they often do not decide whether to buy your product. Who is "signing the checks," and what's on their minds? What's happening in their industry? What are their alternatives to your product?

When you have delved into the topics on this list and have gone as far as possible, reach out to co-workers in other functions with a specific request. Asking for fifteen minutes to get input on a new strategy or ask questions about machine costs often goes over better than an hour to "pick your brain."

I've realized a lot of value from these conversations throughout my career by using techniques from other disciplines to work more effectively with customers; this article covers how working with sales teams has influenced my approach.

How do you demonstrate business acumen?

Gathering knowledge isn't enough, you need to show your team you're applying it. Here are a few simple, impactful things you can do to leverage and showcase what you know:

1. Enhance your pitches and reviews. The more senior the Product Manager is, the more they can create a compelling view of the future. A vision that incorporates the broader context of the business and discusses how you can use product changes to reduce cost, open up new sales channels, or improve customer success will set you apart.
2. Turn stakeholders into co-owners. Nothing is more effective in getting things done cross-functionally than aligning your goals. Involve a few trusted cross-functional partners in your plans from the early stages to get their input and include broader business considerations by design. When people feel a sense of ownership, they are much more likely to endorse the project and help move it forward, even if it's a tough sell.
3. Bring what you learn into the product development organization. Share what you know with your engineering and design partners, solicit input, and invite them to meetings. Engineering, in particular, can get very isolated from the rest of the organization and told to focus on coding, which separates them from the rest of the organization, and from seeing the impact they're having.

Highlighting business acumen for PMs is a green flag. It's saying the company needs and expects its product team to be integral to growing the business and making it successful. It's a strong signal that they don't see the product development team as ivory tower R&D or a feature factory but as a strategic partner.

Business acumen is vital for Product Managers, enabling them to make informed decisions, drive growth, and work effectively across functions to impact the whole business. By developing and demonstrating your business acumen, you'll be better equipped to excel in your PM role and contribute to your company's success.

Eleanor Stribling is a product leader, people manager, and coach with over a decade of experience building software and engaged teams. She’s currently a Group Product Manager at Google, and previously worked at Microsoft, TubeMogul (acquired by Adobe), Kevala, and Zendesk. Formerly an aspiring opera singer who holds a BA in Political Science and History, Eleanor is passionate about helping PMs with non-traditional backgrounds excel in the field; learn more at eleanorstrib.com.

Business Acumen for Product Managers: Why it’s crucial and how to develop it was originally published in productized on Medium, where people are continuing the conversation by highlighting and responding to this story.

2022 is my tenth year of being a Product Manager. In this series, I’ll share what I’ve learned, the highs and the lows of this unique and challenging role in the software industry.

Ten years ago, in 2012, I was very nervous to start my new product management role in an ad tech start-up.

Looking back, the conditions for making that change seem almost ideal. In 2009, I founded, then led, the account management team. I knew the customers as well as all of our two dozen engineers and had collaborated with all of them before. But even with that knowledge and political capital, I was scared to look stupid or mess things up.

I needed advice, so I turned to my network and found a few experienced PMs to ask for their takes on how to do this new role well and where it might lead. Most of those conversations were over email, and when I went idly looking a couple of weeks ago, they were right where I’d left them: in my Gmail archive.

Here’s what I asked, the answers I got, and how I would answer these questions myself today, ten years later. Every so often I still worry about looking stupid or messing things up, but I’ve mostly come to terms with it.

Q. What makes you a successful PM? How do companies evaluate you?

Why I asked

I had no idea and, being only the second product manager in the company I didn’t have any point of reference.

The answers I got

• Ship things
• Have a clear vision you can articulate and resonates with people
• You’re a mini CEO
• Consistently show results
• Ensure people enjoy working on projects with you

How I’d answer this question today

Fundamentally, product managers are there to build things that customers need, which should ultimately mean you’re helping the company to grow. Most companies have a culture of rewarding shipping new products and features with your name on them, and that is important.

However, a sign of a well-run product organization is that they also reward the impact of what you deliver to customers. The first is the impact that your work had on customer satisfaction and/or growth/revenue. The second is that you are a force multiplier who is creating clarity and enthusiasm around customer challenges and what you’re building to address them. These two things require a lot of other skills to pull off successfully that will grow your career in the long run.

I’ve never been too enamored with the “mini CEO” philosophy — one of the most important elements of being a PM is leading with influence over authority, which is not a requirement for a CEO. Unfortunately, this is also interpreted as “you should be like Steve Jobs” by people who forget how poorly he managed his team and stakeholders. Not the person to emulate (that might be another post).

Q. I don’t come from a technical background…I know clients and the user side of the product well, but not a lot about how it’s built. Any tips on working with the engineering team, and learning enough about the tech to have a general understanding of what’s involved in making changes?

Why I asked

The most intimidating thing about the job change was feeling like I had to get buy-in from a group of people whose job I didn’t fully understand and seemed extremely inaccessible and complicated.

The answers I got:

• Learn something about how to code to make sure engineers can’t “bullsh*t you”.
• Be clear about what the priority is from your point of view (e.g. we really need to think this through and future proof vs it’s ok to move fast and have a bunch of bugs).
• Don’t mix up technical terms, you may not need to know much about them, but you may need to look like you do.
• Think about why engineering should trust you and make sure you build that trust with them.

How I’d answer this question today

You don’t have to be super technical or get deep into the code to build a great relationship with your engineering team. As with most relationships, I think it really comes down to trust and respect.

Trust in my experience is rooted in the clarity and focus you can provide. It means you will do everything in your power to ensure that the team is working on the right things at the right time for the right customer and that direction is understood and supported up the chain. It’s also about making your requirements clear from a product and user perspective and being able to say no to random requests from other teams and customers when they don’t make sense, even if they are very loud and would be cool to do. Use data.

Respect is about valuing engineering time and expertise via empathy. Take time to understand the processes, pressures, and incentives your engineering team is experiencing — they are almost always related to yours but not the same. When they bring up a concern or question, listen, acknowledge and do your best to answer. Take time to understand the tech at a high level and ask questions. Never dismiss concerns about tech debt or things that would make the team more productive. Acknowledge hard work and great solutions. Stay humble.

I’m pretty confident no one has tried to “bullsh*t” me. That was probably the worst advice I got. I’ve never had a reason to be that cynical about anyone’s motives, and I try not to guess.

This isn’t exhaustive or anything mystical, and it can still be really challenging to get right (I’m still working on it). One thing that has surprised me over the last decade has been how much I love working with engineering and how little my not being familiar with specific technologies or the details has really mattered.

Learning a programming language and building some small apps helped me to both empathize with and understand engineering. I wrote about that experience in this post about becoming “technical”. Later this year, I’m launching a book that’s the explanation of high-level software concepts I wish I’d had when I become a PM.

Q. What are the potential career paths for PMs, as individual contributors or managers? Do you see a lot of people going into different areas, or staying in the field?

Why I asked

The path I had been focused on led to more senior client service and operations roles with relatively large teams, while I had no idea how product management careers progressed.

The answers I got

• CEO eventually, maybe?
• Most people stay in product and in individual contributor roles for a while
• Getting into product at the best/hottest/most prestigious companies is competitive, and it stays that way (including from engineers wanting to become PMs)
• Management roles are scarce and also competitive

How I’d answer this question today

This was probably the set of answers that are most aligned with how I’d answer now. If anything, I think the field is even more competitive in 2022. There are a lot more content about product management, a lot more frameworks, more certifications, and programs. And a LOT of talented folks.

The current CEOs of Alphabet and Microsoft are former PMs, and start-up CEOs (many ex-PMs) act as the first product person. I’d add that Chief Product Officer or (S/E)VP of Product are great aspirational goals if you want to manage people. I’m hopeful that more companies create exciting career paths for senior individual product contributors, similar to a principal or distinguished engineer — while great PMs are all leaders, managing people isn’t something you should have to do to grow.

A post that’s been on my to-do list for ages is PM manager vs IC PM — maybe 2022 will be the year I get that written.

Thanks for reading, and stay tuned for the next part of this series in February.

Any topics you want to hear about? Leave your suggestions in the comments.

A Decade of Product Management: First Advice was originally published in productized on Medium, where people are continuing the conversation by highlighting and responding to this story.

After almost nine years in Product Management, I’m finding that training specific to PMs doesn’t teach me much that’s new or useful, so I’ve needed to expand my horizons and delve into different subjects.

In this post, I’ll take a look at learning about System Design: what it is, why it’s useful for PMs, and introduce a few resources from which I’ve derived a lot of value.

What is System Design?

System design is about defining requirements to produce outcomes you want. It also includes defining and designing the components needed, how those pieces are constructed, what inputs the system will accept, and how they interact to produce the desired outputs. There’s also an element of designing, or at least vetting, processes that go through the system to ensure they’re working as intended and to maximum efficiency.

In software, we often refer to this as “architecture,” but System Design isn’t exclusively a software thing. For example, in my previous career in the Ontario Public Service, the bureaucracy was a large, complex system where I worked on processes: preparing briefing notes for Ministers and getting approvals for a new mentorship program.

While Systems Design isn’t usually called out as a core skill for Product Managers like other concepts like Design Thinking, I think it’s an excellent complement to the usual trifecta of business, design, and technology. It encourages downstream and upstream thinking and, while it’s traditionally applied in engineering, can be extended in the hands of a skilled PM to help them work across disciplines.

Resource #1 — Educative.io’s “Grokking the System Design Interview”

This is an interview prep course aimed at engineers that I found via a Quora post about a year ago. While PMs aren’t the intended audience, the material is incredibly relevant, and it’s much more about critical thinking and systematic evaluation than writing any actual code.

The course is very accessible regardless of your background because it teaches the concepts by deconstructing parts of applications you already know, like Instagram, YouTube, and Uber. It also goes through a standardized list of steps for each example, providing an implicit starting framework for your projects; even though you as the PM might not own every step, it’s a great refresher on engineering considerations that will at minimum help you to ask the right questions of your dev team.

If there’s a con, it’s the repetition and lack of variety. It’s useful for interview prep, and as a starting resource, it’s not a clear path to mastery, and it doesn’t really push you to think beyond the limited framework.

As of this writing in November 2020, it’s $79 USD for the course or $29.99 USD a month for access to everything on the site. While I didn’t track how long it took me to work through it, the author’s estimate of 20 hours seems about right.

So if you’re looking for a lightweight, flexible, low-cost option to dip your toe into the field or prep for an interview, this is a great choice.

Resource #2 — eCornell’s System Design Certificate

Cornell University’s online school offers this credential earned by completing seven two-week courses, each introducing a different concept or tool. The program is taught by a professor and a “TA” (usually an adjunct with a Ph.D.) who answers questions, moderates discussions, and evaluates assignments. This makes it much more in-depth than the evaluative.io course. However, the program is still very practical, and students interrogate the concepts with real-world examples.

Before I committed to the program, I tried to find resources on the concepts outlined in the descriptions and didn’t have much luck finding good explanations, certainly nothing structured. Despite the broad applicability, the examples are engineering-centric but more mechanical engineering than any other field, which was refreshing for me coming from a software background.

While the material was well-organized and well-taught, I’m still thinking about how to apply them best. Some of the tools are very complex, aren’t well known in software, and would be especially difficult to use as a group remotely. That said, there are about half a dozen really excellent concepts and templates that I’ll be adapting and implementing in the next couple of months, so I think it was very worthwhile.

If you want to build some knowledge casually, this isn’t the best choice. While the timelines are very flexible, if you pay the whole tuition upfront, the courses are labor-intensive, short, and cover challenging material. Because they begin on Wednesday mornings and I was working full-time, I often didn’t get to the coursework until Saturday morning and constantly felt like I was playing catch up.

All of that said, it was a fun set of courses with material I doubt I could have found anywhere else, and I got a certificate from Cornell at the end, which is a nice perk! The cost will be a barrier to some folks, though: as of this writing in November 2020, the program will run you $4,200 USD or seven payments of $650 USD. When I enrolled near the beginning of the pandemic, there was a 30% discount on the program, so keep an eye on their website for promotions.

Resource #3 — Books!

If you want to chart your own course, there are many great books out there. These are my two favorites, both great but very different:

Thinking in Systems: A Primer by Donella Meadows
This is such a great book, and I often reach for it when I’m thinking through a tough problem. It’s a primer for systems thinking, so it’s not as tool- or software- oriented as the eCornell program, but the concepts are foundational.

Designing Data-Intensive Applications by Martin Kaufman
This book isn’t labeled “system design,” but if you’re in software, it might as well be. While the focus is on data, it covers many of the same themes around scalability and complexity that the educative.io course does, but in much more detail.

If you’re looking to level up your PM practice, I hope you got some value from this post and the recommendations. Add your favorite resources in the comments below — I’m always looking to learn something new!

System Design: 2 Courses & 2 Books to Improve your Product Management Practice was originally published in productized on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this post, I’ll explain what crossbows and firearms on the battlefields of 16th Century Europe can teach Product Managers today.

CW: Violence, weapons, and warfare from this point forward.

When I was growing up, one of my favorite places to go was the Royal Ontario Museum (ROM). A few days ago, I was excited to find a show on Prime Video called “Museum Secrets,” where the first episode focused on the ROM’s collections. While the episode covered a lot of ground, it was the segment about why guns replaced the crossbow in European warfare that reminded me how important time to value is in making a successful product.

A Tale of Two Weapons

Crossbows were used on European battlefields between the 10th and early 16th centuries. They were not a new or exclusively European phenomenon. However, they enabled a new class of professional warriors who didn’t need the same lifelong training that archers using a longbow did. It made it easier to train new fighters, and cheaper to replace them where necessary.

By the 1520s, guns eclipsed crossbows.

To our modern ears, even though hunters still use the crossbow, this development might seem obvious. But in the early 16th century, guns were very different than the firearms we have today. In the video, it takes about a minute and multiple steps and pieces of equipment to load the gun, as well as requiring the soldier to carry and pour gunpowder into the chamber and the barrel and often light a fuse to get it to fire, which looks kind of terrifying. The crossbow takes about the same amount of time to arm in the video but requires just the weapon and an arrow. The gun requires gunpowder poured into two chambers, two wads, a lead ball, a rod, and a fuse.

When I watched the professional marksmen fire the crossbow and the gun in “Museum Secrets,” the crossbow seemed like the superior weapon. It’s when the curator tries to fire that why the gun won out becomes apparent: it’s easier to learn to fire it accurately, and it can do a lot more damage to a target.

The “Schmuck Factor”

When I first saw the segment, I thought about this as an ease of use story, but quickly realized that’s not exactly right — early guns were hard to load, even if they were easier to fire accurately. And there was switching cost: adopting guns required that every operator learn new technology and possibly purchase a new weapon.

What the curator says at the end of the segment made me think about it differently.

What that means is you could take someone off the street and make them a competent soldier in less time. In the segment, they refer to this as the gun’s “schmuck factor.”

It’s also important to consider the “You” in the curator’s statement: the people in power — ranging from militia leaders to local lords to monarchs — who were responsible for maintaining a functioning fighting force.

Guns enabled military leaders to quickly train a non-professional “army” on a weapon that they could get reasonably good at using very quickly. And if those soldiers were lost in battle or reinforcements were needed, training their replacements was relatively easy. In other words, guns enabled a rapid and comparatively high return on time and resources spent on recruiting, feeding, and transporting soldiers, while creating a bigger pool of eligible recruits.

While the adoption of guns wasn’t without controversy, it had clear benefits for military leaders. Compared to the crossbow, guns made the average recruit deadlier, faster. And that helped leaders achieve their goal of winning wars.

Lessons for Product Management

What does this story about 16th Century guns and crossbows have to do with Product Management today?

My main takeaway is how crucial time to value can be in product success. And time to value comes down to the benefits of learning the technology, addressable market, and consistency of results.

Good UX isn’t enough; it helps, but it’s not essential if the user can be quickly trained to achieve consistent results.

The underdog product won out not because it had better features per se, but because less training and aptitude was needed for people to use it and help reach the ultimate goal.

Even if the underdog product requires operators to learn an entirely new technology, if it’s not a significant investment and they see an immediate payoff, the product has a chance of success.

If you’re building a new product competing with a popular alternative, be sure that:

• Using it is easy to learn for a wide range of people in your target group
• Demonstrating that consistent, superior results are possible when that basic knowledge is in place

If you’re the owner of the incumbent product and a new player like this comes along, consider:

• Leveraging existing expertise of your user base to make the product more effective and switching cost higher
• Improving the quality and consistency of results your core product delivers
• Making the product easier to pick up and use for a broader base of new users

History can teach us a lot about how to develop successful products, whether you are managing today’s ubiquitous standard or the next new thing.

How high time to value can sabotage your product was originally published in productized on Medium, where people are continuing the conversation by highlighting and responding to this story.