Tips for starting off as a new b2b product manager
By: Kevin Capel
Tags: Product Design, UX, Startup, Product Management, Product Development

Starting out as a new product manager or product owner can be daunting. You might have questions like How much power do I actually have? How do I know whether I’m making the right decisions? How do I know what to work on next? While the art of product management is learned over years, I’ve seen some common patterns emerge especially when new PMs are just starting out. Use the following tips to help make a great start:

Push valuable work vs. logical work

Define a clear product vision

Find a strong designer ally

Base product decisions on client and user feedback

Don’t get attached to any one solution (especially your own)

Take initiative to solve even tangential problems

Avoid working on everything

Push valuable work vs. logical work

Whether you’re a brand new hire or promoted up from within the organization, it’s extremely likely that you will start off with a mountain of pre-existing ideas and requests formulated by others about what your product should be and what it should do. While this task of getting your head around a collective set of external problems might initially plant some seeds of doubt (like any good product manager), making sense of the existing backlog and set of customers' desires is absolutely imperative before embarking on development.

Because there is often an incredible amount of pressure on product managers to do, it can be tempting to work on something, anything, just to keep the team and developers moving and therefore quell executive fear of lost productivity. Under these circumstances, especially if you already know the product, it’s tempting to work on the logical vs. the valuable.

Some examples of logical extensions to a product:

Exposing additional data in searches, pages, exports, etc.

Taking an audit of access control permissions and adding more

Adding custom, user-created content, to other pages, too.

Building a new dashboard widget to make other data more accessible

While some of these ideas may indeed be valuable and logical in some cases, I’ve seen a trend to work on what is known vs. what needs to be. In this case, extending an existing feature of the system might seem like a safe, rational bet, however, it robs you of time that should be spent working through other work that is more valuable work that allows you to win new deals, recognize revenue, buy political grace, expand the product’s audience, etc.

If you find yourself generating ideas from existing feature sets because they could be better, pause, and take a step back. Almost all of your work should be generated or influenced by direct client feedback and validation or objective analytics. Don’t mistake logical ideas for the right solutions.

Instead, if you need to keep the team working despite a strong client-driven roadmap, shift gears towards technical debt — bugs, monitoring, analytics, performance improvement, scalability issues, etc. This will make the existing platform more stable without introducing new work that does not yet have a solid foundation in client feedback. Chances are developers will also revel at the chance to fix long-standing issues while a new course is set. This can buy you time to validate your backlog and weed out ideas that don’t help you meet a goal.

Define a clear product vision

A natural consequence of starting a new job (let alone sometimes learning a new industry!) is trying to steer the team towards a goal. What goal? For whom? How should the team make decisions about what to do and what NOT to do? What is the why behind the what?

I’ve all too commonly seen new product managers take the path of “going with the flow,” especially as not to seem “dumb,” behind, or ineffective when it comes to product decisions. Nodding and saying “yes” to executives is all too easy to do given the pressure to perform.

Resist this notion to the best or your ability without sacrificing cooperation and positive energy. Instead, ask all the “dumb” questions and craft a product vision first. It’s imperative that the team starts out on a solid, well thought out foundation. If too many assumptions on the why and what are made up front, it will be much harder to go back and reconstruct the right answers later on, let alone realize that the course you’re on is the wrong one!

I’ve seen a few players do this very well. If you do not understand why stakeholders or your team are pushing for a certain feature set or why your boss wants you to do x next, politely ask if you can meet for 30 minutes to ensure you’re armed with the right details. Use this time to ask questions and dispel uncertainty even if your questions seem simple. You’ll often find that the answers to some questions reveal a world of unsolved problems or lack of direction.

Asking tough questions can also do double duty by instilling confidence from your boss that you’re heading in the right direction, are engaged, and leaving no stone unturned.

After getting through a key point, repeat back the conclusions that you just made so that you can drive consensus. This is also an opportunity to write unanswered questions down and drive the team towards answering them together later on. A collective consensus on the basics will do you a world of good later on.

Find a designer ally

All too often I have seen UX left on the sidelines when a new PM or team kicks off because there can be seemingly more important things to get right first. This comes at no surprise — making sense of the product and its goals is indeed important and can be all-consuming at the start.

Despite the seeming runway you have before development really gets going (and when you will need visual designs) bring in your UX resources early and at the start of all team talks. You’ll need your designers to understand the what and the why just as much as you’ll need them for design decisions. This helps build trust between designers and PMs and fully allows them to be a part of a team, even if a formal team allocation is lacking.

If you’re blessed with a dedicated designer for your team only, find some separate, uninterrupted time to talk through your strengths and weaknesses so that you can learn to work together well.

If your organization is just coming on board to see the value of UX or doesn’t have any UX resources at all, fight for your design resources here as much as you can while still remaining kind and cooperative. You may need to manage up and try to convince stakeholders of the value of UX and why a designer is needed.

As time goes on, you’ll need a good designer as an ally to help cut through confusion and uncertainty. This is even more true if you are building a product from the ground up vs. extending an existing product.

Base product decisions on client and user feedback

Based on the sheer number of decisions that you need to make daily, it will be tempting to push through work that seems solid without gathering client feedback just to save time and remain efficient.

(In a somewhat patronizing tone) — Do I really need to show this new data column design to clients for feedback? Isn’t it obvious?

Yes — you do. When it comes to making product decisions, reaching certainty about adding value is one of the best things you can do. All too often have I been surprised by client feedback on seemingly simple adds to the system even when it came from the client directly. This is often because a client’s needs are much more nuanced and complicated than even one person can understand at a time (even more true for enterprise agencies that have years and years worth of embedded workflows that no one can explain!).

Showing clients designs and or business logic in advance of development does many good things:

It allows you to garner respect and build confidence with your clients (especially when you’re spot on).

and build confidence with your clients (especially when you’re spot on). It gives you more time to build relationships with client stakeholders.

to build relationships with client stakeholders. It allows you to catch mistakes early and thereby keep costs low. A problem that never exists is much less expensive than the cost of bad design. Even catching just 1 mistake in 20 is a value add.

early and thereby keep costs low. A problem that never exists is much less expensive than the cost of bad design. Even catching just 1 mistake in 20 is a value add. It creates certainty that what you are building will correctly solve a problem. When you need to make a call down the line about what to cut, you can rest assured on cutting those things that you assume provide value vs. those that you know provide value.

that what you are building will correctly solve a problem. When you need to make a call down the line about what to cut, you can rest assured on cutting those things that you assume provide value vs. those that you know provide value. Allows clients to expand on businesses cases and reveal logically related problems.

If you find yourself pushing invalidated work through the queue just to keep things moving, take a step back and setup even just one or two short calls with a few trusted clients. You can use the session to get feedback on multiple designs or proposals at once — this can often be done in 30 mins to an hour.

Don’t get attached to any one solution (specially your own)

Based on increasing familiarity with a product, it may be tempting to think you’ve got the solution figured out before taking the time to explore additional business needs. It goes something like — yes, yes. We should do it this way. Let’s go!

Upon further analysis, you might find that solution isn’t quite right, especially if you do not spend enough time working through the identification of business needs vs. product requests/desires. If you make assumptions about a solution too early and start development right away, it will seem very hard to go back and admit a mistake and start over later on. After all, you don’t want to be seen as wasting the team’s time on something that won’t get finished. This is even harder when the idea is yours and you have some stake in it.

Let go of your ego and admit the mistake. Completing development on the wrong solution just to “finish it” is not valuable. Recoup what you can and go back to the fundamentals by identifying a clear business need and gathering feedback on designs that intend to solve it. Shifting gears towards a validated solution is always more valuable than solving a problem that does not need to be solved or should be solved in a different way.

At some point, you will realize you shouldn’t have done a feature in the way you did. Learn from this for next time and learn to spot any unjustified affinity to a particular solution when the evidence points elsewhere.

Take initiative to solve even tangential problems

Product often solves problems that other departments don’t simply because there is no where else to go. You might find yourself wondering things like:

Why isn’t support knowledgeable enough to answer questions on this feature that has been out for years?

How come there is no testing plan in place already for this import process? QA?

I didn’t build this feature — I don’t know why it was done this way. Who should this question go to?

Building a product is tricky work — aligning cross-functional teams that all have their own problems to solve comes with some things that simply don’t get done when they should. Instead of waiting for other teams to play their role to a higher standard, take initiative and work with leaders of other teams to help fill in the gaps. This might look like meeting with department heads and coming prepared with examples of problems and how they affect the product and end user outcomes.

If the product is successful, you will be successful. If it is not, it won’t be as easy for you even if it’s not directly your responsibility to fix. If you take initiative and look for solutions to solve existing gaps, more often than not others will recognize your lead and get things moving in a better direction.

Avoid working on everything

Lastly, it may be tempting to work on everything. After all, everyone’s desires and needs are important. Cutting a feature from the product or sending it to a later release version may evoke disappointment from stakeholders or clients. It is not fun to be the bearer of bad news.

However difficult, if there are more requests and work than there is development and designer throughput (and this WILL happen), you’ll need to ruthlessly prioritize what work gets done and what does not. Do not make the mistake of trying to solve too many problems at once. Pick only the top 3–5 problems at a time and focus on solving them well. Only then is it appropriate to open the queue back up for discussion about what’s next. Chances are the landscape will change in this time anyway.

Learn to direct your team’s energy

Half the battle of product management is learning to recognize where to direct the team’s energy —this requires constant shifting and correcting to get right. So, too, will you need to adjust your strategy to get the team there. Use these tips to make a great start and venture into the b2b product world well.