Attention to Detail: The Skill that Enables Highly Effective Product Managers
When I included “attention to detail” in my key product manager skills, I knew it was important, and I had examples in my head of what I thought I meant, but honestly I did not realize where this definition would land. First off there are a lot of muddled expressions that are all semi-related. There’s “being detail-oriented,” or “having attention to detail,” and then there is “paying attention.”
Paying attention is the ability to absorb details as they come in. It’s about aperture. If you and ten other people listen to the same customer interview, look at the same picture, etc will you remember more details about what you encountered than everyone else? This is really about your ability to focus in the moment, drown out noise, and retain information. While this is important for many reasons, this is actually not what I’m talking about.
For product managers, having attention to detail is really about completeness of thought, thoroughness, and ultimately the quality bar you hold for your work, the work of your team, and the company. It also relates to your ability to make good decisions. If you do not have a full grasp of the details, you may get lucky, but it’s more likely you’ll miss a key exception that would have steered you down a different path. This is true for entry-level product managers and senior product executives alike.
As an IC Product Manager
As a hands-on product manager working with a development team, attention to detail surfaces as the completeness of your understanding of your part of the product, it’s place within the larger offering, and the needs of your customers. If you are thinking things through in enough detail, not only will you have a better chance of achieving your goals, it’s also a great way to suppress risk. There are volumes of articles on the uncertain nature of software development, inaccuracies of estimates, etc. We spend a lot of time forcing engineers to make educated guesses about timelines. More often than not the things I’ve seen lead to estimates being wrong is not the engineers misestimating the work, it’s not having properly understood the scope at a sufficient level of detail to anticipate the work that is required. Missing a dependency, finding additional scope late, doing rework to avoid a blocker, etc.
A lot of time with junior PMs (and sometimes more senior ones) there is too much focus on “delivering something” and “doing it fast.” Delivering something of value to the company and the customer, doing it well, and improving on it requires a little more discipline than being a feature factory and optimizing for total pounds of software shipped.
Everyone has the same amount of time to spend, and the “quantity and speed” oriented product managers do just that. They spend most of their time superficially thinking through lots of initiatives and ramming them into development without proper consideration. Goals are not properly understood, acceptance criteria are weak or non-existent, downstream impacts and dependencies are not appropriately considered, and sales and marketing support forgotten. A half-baked feature either launches into the dark, or the schedule explodes because engineers find something major that was never considered after the project is already in flight. It’s easier to appear to be doing “more” and doing it quickly, but I’ve often found these features don’t work, have a lot of issues, take longer than expected, and don’t have really any positive business impact.
I used to have a picture like this on my wall in my last office. Even adding a stupidly small feature requires a ton of hidden detail to be considered. You don’t need to dwell on all of it or be paralyzed it, you just need to be aware of it and act on the stuff that matters. Running through an exhaustive list of potential considerations quickly will lead to a less risky decision with a better chance of positively impacting the metrics.
Example: “Can we add a single link to the top navigation of the home page for X?
Seems easy, should be simple. Your brain should play through:
What is the measure of success? Why are we adding this to the nav? Are you saying you need a hammer when you really need a screwdriver?
Do I understand why it looks the way it does before I start changing things? Who can I ask about why the nav is structured the way it is presently?
Who are the users of this page and what goals are they trying to accomplish? How will I quantify if I made things better or worse for them?
Is this as simple as “adding something” or does it fundamentally change the information architecture of the page? If we add a new top nav major category, does it mean we should leave everything else as is, or is the right thing to do to reorganize sub-nav elements to make more sense to the target users?
How will this change reflect on different device types, browsers, and screen resolutions? Is this the extra nav element that causes things to wrap in an ugly way? Is it still worth it?
Is it actually technically easy to isolate just the homepage nav or is it a shared nav across all pages and we’d need to create a new version and update other pages?
Assuming it is technically simple, does it make sense to try to make other changes that have been “saved up” and do a large reorganization in context of everything or does it make sense to keep this targeted.
Is this likely to have a big enough impact on important KPIs that we’d need to do an A/B with the current design to ensure we didn’t break anything important? Given the traffic on the page, how long would it take the test to reach significance?
Do fewer things, do them well, think through them more carefully at each step and you’ll see happier customers and improved metrics. Be the fine craftsperson, measure twice and cut once, look for the impact, iterate, continue. Anyone can ship a giant pile of features, but it doesn’t mean you’re building business value or effective at your job.
As a Product Executive
When you move up to more senior roles, the need to have attention to detail does not go away, it actually expands and changes on a few dimensions. Somewhere in your company, someone has an unruly spreadsheet that is the financial model for the business at a painful level of detail. Go find them and set up some time to have them walk you through every corner of the model. This is where your ability to understand systems thinking, and the fact that all of these variables are interconnected with each other and the product is critical.
As an IC you are trying to move one or two main KPIs that may not even be a direct financial metric. As the VP Product or CPO you still care about the product metrics, but ultimately you’re focused on growth, revenue, and profitability like all of your peers. To be able to understand where you should focus the efforts of your team to drive business growth while staying consistent with your strategy, you need a very detailed understanding of the entire business model. Acquisition economics, sales efficiency, margin and profitability, and retention - all of it. The earlier in your career you can start thinking this way and understanding the complex system that is your business, the better prepared you will be to move up into more senior roles.
Moving up also necessarily pulls you out of the details of each of the product teams. Assuming you’ve hired product managers you can trust to make autonomous decisions, then you need to adjust from being in all of the details, to inspecting to ensure all the appropriate details are being considered by your team. This is really just using your 1 on 1 time with direct reports effectively and asking a lot of questions.
You’re not telling them what to do, but you’re asking a lot of questions about what they are doing, why they reached the conclusions they have, what are they doing to account for X, and what they would do if Y happened? By asking a lot of specific questions you are demonstrating the level of detail you expect your team to have in their head when making critical decisions. Sure it helps you to stay informed, but really it’s setting the quality bar for detail-orientation, thoughtfulness, and decision making within your organization.
If your directs don’t know some details you’d consider basic, then you have to question the validity of some of the decisions they are making each day. It’s not a reason to panic, however it points you to where you need to coach and guide your team more actively. Your ability to not have to micromanage people is directly correlated to your trust in their decision making ability. Their grasp of the relevant details, and genuine interest in doing so, is one of the key inputs to good decision making, so it’s worth inspecting on a regular basis.
The last bit where detail orientation pays off is in the bigger strategic conversations. It’s easy to assume that strategic vision is about big ideas, not small details. Well, kind of. Compelling strategies are developed from a deep understanding of the details. Strategy is a summary of the details that is easy to digest and communicate, but they are not devoid of details. Strategy is about choice - and as this article highlights, if your strategy is nothing more than a tagline, the rest of the org will struggle with how to execute. Which specific KPIs are we aiming for? What are the constraints? What’s assumed? How does all of this map back to driving the financial model in the way we want?
Summary
Product management is an extremely dynamic and complex role that is best suited for those with an ability to constantly absorb and consider a large amount of detailed information. As an IC Product Manager you should try to focus your efforts on doing fewer things extremely well, especially if you have found it difficult to achieve product and financial objectives. If your projects keep having surprise scope expansions or post-launch customer issues, think of what you could have thought through ahead of time to avoid this issue.
As a senior leader, the need to be detail-aware does not go away, it expands and you need to apply it in a different way. You set the quality bar for your organization by expecting a strong grasp of the details from every member of your team and by doing so improve the quality of decision making within the group. You need to intimately understand all of the details of the company financial model, the current product offering, and the company and product strategy. How do all of these systems interconnect and reinforce each other? Where does it make the most sense to double down internally, where would it be faster to buy or OEM technology instead?
As a product manager, if you learn to embrace the details you’ll be amazed how you will make better decisions more quickly than you thought was possible.
