5. The Business of Product is Business
For many designers, business is a dirty word. It conjures up images of “suits” who don’t care about users — er, humans… no, people — the way you do, of bean counters, and of overseers cracking the whip and driving “death marches” to hit arbitrary dates and ship the requisite number of lines of code.
This isn’t fair, of course, and not only does it represent a barrier to overcome if you want to go down the product management career path, but any such aversion to the business side of software development can hamper your UX growth and development as well.
Towards the end of this year Rosenfeld Media will be publishing my book Product Management for UX People: From Designing to Thriving in a Product World (you may sign up there to be notified when it is available for order), the culmination of a multiple-year project that has unfolded with the input and support of the Design in Product community.
During the editorial and production process I am sharing early drafts of chapters, and I welcome any feedback here that will strengthen the material.
Build Sustainable Value
As you know by now, the role of a product manager is to build value. This goal deliberately leaves unstated to whom that value accrues. As a user experience expert, naturally you will think in terms of valuable experiences, of your customers deriving value from using your product, as you should.
The business, the organization building and delivering this software, also needs to reap some of the value being generated, in order to sustain itself and live. Paying attention to that side of the equation doesn’t make you greedy or uncaring, and going out of business because you can’t figure out how to make a living selling your valuable wares will equally deprive your customers of the virtues of what you’re making.
Getting the balance right means neither raking too much value off of the top so that quality suffers nor leaving too much value on the table so that the business fails to sustain itself.
So what is unsustainable value? Offering your services at a loss to corner a market is unsustainable. Building a business that can only scale by adding more staff is unsustainable. Making a profit by externalizing the costs of your business and in the process destroying the infrastructure and environment necessary for the operation of the market is also not sustainable.
To Market, to Market
Both UX and Product Management share roots in 20th century marketing business practices. User experience in many ways is an updated model of understanding and addressing the needs of customers, which has always been the primary goal of marketing efforts, and product management derives some of its DNA from product marketing (and still overlaps with marketing departments around that concept in many organizations).
Product management goals often revolve around the cycle of:
- Targeting a juicy market
- Deeply understanding its problems and needs
- Designing and developing a solution to that problem, and then
- Figuring out a way to bring the solution to the target market
Wait, what is a market?
Sometimes we hear a word so often we don’t stop to think about what it means. Market can mean several things, of course, from the place where people buy and sell (such as a farmers market or supermarket), to the more abstracted markets where securities are exchanged, but in this context the word market really just means “a specific category of potential buyers.”
Sizing a market
When trying to determine what market to go after, or if a particular market is large or needful enough to sustain your line of business, it’s tempting to cast the net as wide as possible. Who is this product for? Everybody on the planet! Adults age 24 to 65. Right-handed people! But the problem then becomes “how do you target such a vaguely defined heterogeneous group?” If you’re not selling fizzy sugar water, how do you leap directly to mass appeal?
Now if your target market is “adults in the United States aged 18–35 who are thinking about buying their first new car,” you’ve got some definition there to work with and a much better chance of crafting experience and narratives that reach this market.
Once you have a handle on the types of people you are trying to serve, you can do some basic Google-type research to get a rough idea of the size of that market overall. Then you’ll need to come up with and justify the percentage of that market you think you can reasonably obtain as customers.
From the Trenches
Honestly, 90% of “research” for product managers is just “Googling stuff.”
~Matt LeMay
Here is where numeracy really helps. It’s amazing how often people reason about markets something like this: “Well, there are a hundred million people in my target market, so I only need to reach 10% of them to have ten million customers!” or even “… I only need to reach 1% of them to have a million customers!” and sure, 10% is only a small part of the whole and jeez 1% is tiny! but this is an illusion based on the huge denominator (Figure 5.1).
It’s not significantly easier (or even necessarily easier at all) to reach a million customers out of a target market of a hundred million than it is to reach a million customers out of a target market of four million. It definitely affects how and where you target your messaging and how you understand the needs of the market segment you are going after, but having a rough ideas of the size of the potential market is really just the first step.
Gauging interest
Once you’ve identified your target market, it’s time to better understand what the people in that market are crying out for and whether what you are offering (or planning to make for them) is even something they would need.
UX Superpower Alert
At this point, you should be back in your own wheelhouse! After all, we’re talking about user research now, so you can draw on all of your previous skills and experiences. User experience research is no different from market research — after all, you’re looking to identify potential customers, pain points, needs, and mental models.
There are many ways to gauge interest in and validate an idea. Some are more qualitative to the point of being anecdotal or potentially limited to confirmation bias if you only investigate likeminded people and other methods are more qualitative and evidence based.
One product I worked on, CloudOn, was a document editor for iPads before Word or Google Docs were available there. Jay Zaveri, chief product officer (and my boss and mentor at CloudOn), established that there was a market demand for “Word on the iPad” in the face of skepticism that anybody would want to do “real work” on a tablet.
The way he made the case to the rest of the leadership team and the company’s board was by taking out a relatively cheap Google AdWords buy that said something along the lines of “Word is coming to the iPad! Sign up to be notified when it’s here.”
Author’s Note: This is sometimes called a “smokescreen” test. Some also call it a smoke test, but that expression has another application already: a rough test of a bit of code to make sure nothing breaks when you run it (making sure the engine “doesn’t start smoking” when you fire it up).
He quickly gathered thousands and then tens of thousands of email addresses from people who were eager to do productive work on their convenient portable touch screen devices. Not only did the upsurge in interest help justify the R&D direction that eventually led to a native gesture-based document editor for tablets (and a collaborative model for working with cloud documents that lives on today after CloudOn’s sale to Dropbox’s in their Paper product), but it also helped with the initial go-to-market plan.
What is a go-to-market plan?
Another common use of the m-word that you’ll hear doing product management is the phrase “go-to-market.” When used strictly this is an adjective describing a type of strategy or plan, also often called a “launch plan” although a product can go through many launches (new versions, key features, and so on) whereas go-to-market typically refers to the initial launch of a new product and its first encounter with the market that it was theoretically defined to satisfy.
A go-to-market strategy is a comprehensive plan to promote awareness of your product in your target market, enable people to discover what your product has to offer, communicate a narrative in which the potential customer is the hero and their heroic journey involves embracing your product, line up and coordinate with partners and other business-development stakeholders, product marketing and potentially advertising materials, set the pricing model for the product, and address the personnel and budgetary resources required to successfully launch the product to its market.
(Going to market generally involves coordinating with other stakeholder groups in your organization outside of the product team, as well — most notably marketing, business development, sales, customer success, and customer support, but others may be involved as well.)
Note from the author: Remember that a launch plan is not a product roadmap, but often when stakeholders ask for the roadmap, they are really asking for commitments about when features are going to ship. More on this later.
“Go-to-market” has also come to be used at times as a noun describing all of the related activities involved in a go-to-market strategy.
In the case of CloudOn, when it came time to ship the version 1 (which was initially called App2You, believe it or not) of the iPad app to the App Store, Jay was able to send a promotional email message to the tens of thousands of eager potential customers who had asked to be notified when it was available
This drove a downloading frenzy that had several immediate effects:
- CloudOn hit number one in Apple’s productivity apps charts the day of launch
- CloudOn hit the top ten list for all apps the day of launch
- The prominent ranking in the charts drove much additional organic downloads beyond the initial group from the mailing list
- This kept CloudOn high on both charts for several weeks as the initial surge gradually wore off.
- CloudOn had to limit downloads the first day because the server infrastructure was overtaxed by the unexpected enthusiasm.
- Jay’s initial “bet” that people wanted to work on their iPads was further proven.
As a product manager you may be involved with or be required to develop go-to-market strategies, or you may work on products that are well established and no longer manage incremental updates and changes in such an elaborate orchestrated way, but nevertheless you are always trying to understand and gauge the needs and frustrations of your target market and every time you experiment with something new in your product you need to bear in mind how you are going to deliver it.
Finding Product-Market fit
The third major sense in which product people talk about “markets” is when using the ubiquitous phrase product-market fit. There’s nothing tricky about these words. It literally just means that the product fits the needs of the market in some demonstrable way. But the phrase is also used to describe a stage in the life of a product or a product company.
So before achieving product-market fit, a product is still in search of a sustainable relationship with its customers. At this stage, it makes no sense to optimize things or to invest in heavily engineering aspects of the solution because you really don’t know yet how badly people want what you’re offering. At this stage the whole job is to find that product-market fit by paying close attention to what initial customers and their behaviors are telling you, by understanding as effectively as you can why non-customers are staying away or failing to convert, and by experimenting relentlessly until things click.
Searching for product-market fit is a huge part of early-stage PM work such as angel-funded startups and enterprises opening new lines of business or launching entirely new products in existing lines. For other PMs, product-market fit is a done deal and the job has more to do with optimizing functionality, growing the market, upselling, and so on.
Now, to be totally honest, as with so many other rubrics, the concept of product-market fit is both subjective and somewhat arbitrary. Like the stone in the “stone soup” parable, it provides an anchoring concept that enables good things to happen, but don’t treat it like an objective yes/no fact. Even if you’re measuring a quantity as a proxy for it, treat it like a qualitative thing.
“If they’ll crawl through glass…”
The holy grail for some entrepreneurial minded product folks is a company that has achieved product-market fit with a lousy product. How is that possible? Well, if people want something badly enough, they will crawl through glass to get it. This does not mean that lining your entranceway with broken glass is a great user experience. It means that what you are offering meets people’s needs so hard that they will put up with a subpar experience to get it.
This kind of scenario is a goldmine because it suggests that simply by improving the product experience in fairly straightforward ways, you will be able to capitalize on the inherent value and appeal of the product experience and service being offered, reduce bounce and churn, help more people understand and engage with the product, and ultimately reach much greater markets beyond the early adopters willing to put up with all those cuts.
A big reason why I took on the head of product role at 7 Cups, a mental health community, was that just a little over a year since its founding as a Ycombinator startup it was demonstrating that “crawl through glass” level of product market fit.
The entire service was built by one engineer using readymade web technologies and services and it had grown in a sprawling organic way by responding to feedback from early adopters, so as a product it left a lot to be desired. It was unfocused. It wasn’t clear how to get started. It offered too many options that seemed similar to each and too many navigation choices, and nevertheless it was growing at a rapid clip.
Whatever 7 Cups had to offer (which was on-demand support from real people, with minimal waiting) was compelling and desirable enough the folks were willing to put up with a lot of subpar “plumbing” and product experience to get it. What a ripe opportunity!
Zeroing in on product-market fit
One of the most effective methods for quantifying product-market fit is to survey existing users and ask them how they would feel if the product went away. Would they be very disappointed, somewhat disappointed, or not disappointed at all?
This is subjective of course, but there is a broad consensus among investors and product folk that if around 40% of your users would be “very disappointed” to lose your product, then you have product-market fit.
So, there are ways to determine whether you have this fit yet, but what if you don’t? If the lack of fit comes from not enough customers who would miss your product if it went away, then the solution is to find and focus more on those customers who are already in your dedicated group (the ones who would be “very disappointed” to lose you).
Can you find more of these people and stop going after the rest? Can you convert more of your customers into feeling the way these people do? Anything you might want to try to do will come down to understanding these different subgroups better and learning what distinguishing them. What are the unique characteristics of the people in your market who are clamoring for your product?
Rahul Vohra, the founder and CEO of an email product called Superhuman shared a pretty good tactical process for achieving product-market fit with a customer base that is not there yet, which he calls the Product-Market Fit Engine. He recommends after surveying customers in the way just described, that you also ask the people who love your product (the ones who’d be very disappointed without out) what exactly they love about it.
Then you segment your users (the market segments will depend on you but one example he gives is segmenting people by job title), and analyze which segments are heavily represented in your strong group.
This enables you to notice which segments or demographics to focus on (the ones most strongly represented among those who love your product), and which to consciously neglect (the ones who wouldn’t mind if it went away). Then by analyzing what people love about your product, you can both double down on these things as you retarget on people like your best customers, and also start to figure out which demographics would be somewhat disappointed but could be converted to the “very” group if you offer them things they will love as well (Figure 5.2).
Of course you need to track each change and measure again with each iteration to make sure you are increasing the loving group.
Customer Obsession
Speaking of targeting the right customers and optimizing for their love, here again the sort of deep study of users that is the bread and butter for a UX practitioner will stand you in great stead in product management. A big part of the PMs job is to obsess about customers and to talk to them as frequently as possible.
You’ll jump at the chance for any new information about customers. New survey responses, updated traffic and behavior data, complaints on social media, reviews on the app store, direct feedback on existing or proposed designs, and more.
The best product organizations will foster strong ties between the product team and customer support, customer success, and community managers who have their fingers directly on the pulse of the user base. These people should be your new best friends. Often they are frustrated by not having a direct conduit to the product team, and have insights and observations to share that are solid gold for your understanding.
You do this in two ways:
- Setting up formal processes for syncing, coordinating, and reviewing data and plans together
- Alongside the formal cadences of checking in, building up more informal, back channel relationships characterized by mutual support and collaboration.
Launching vs. Optimizing
In some sense, most product managers are always launching something. It may not be the debut of an entirely new category-defining product but in any given sprint you might be launching the 4.3 version of your mobile app, or your new search feature, or an AI chatbot, or something on a fairly regular basis. The exceptions to this tend to occur inside huge huge enterprises with 18-monthlong waterfall software development lifecycle (SDLC) processes, or a no-longer-innovative business that forever finds excuses to hold off on shipping anything to avoid rocking the boat.
However, it’s also a generally accepted notion among product leaders that some product managers are better at launching new things and others are better at optimizing things that are already up and running. Again, this need not rise to the level of needing one type of PM to launch your product and another to take over a few weeks later to maintain and optimize it. But on the level of any given product line, product, feature, or functionality, getting the thing to exist at all deals with one set of factors and bringing out the best in it involves another.
It’s a good idea to get a sense of where you think you fall on this spectrum. Do you relish the exhilaration of launching things into the unknown? Are you a skydiver at heart? Do you draw energy from seeing things turn from ideas into reality? Then you’re probably something of an instigator and your energy fits well with innovation and novelty.
Or do you prefer shaping and molding and guiding a team or initiative to its highest level of performance and success? Are you the sort of person who would rather join the crew of a well designed, built, and maintained ship and “find out what it can really do!”? If so, then you might be more suited to taking on an existing product and improving it systematically, finding breakthrough opportunities, growing engagement and profitability, or even evolving it into a platform.
Maybe both of these things sound great and to you and a tight team where individual PMs are given wide latitude might suit you best.
And these aren’t mutually exclusive tendencies by any means. Há Phan, a product leader and general manager at Pluralsight, and one of my product mentors, put it this way:
For a long time I saw myself as the person who always starts things but never optimizes. Then when I started building this team, what evolved over time is I realized that I’m building a platform, building a system. So the system is a long game. You can’t go “short game.”
So that’s actually how I see it now: I’m doing both. I’m always starting new things and I’m always optimizing old things (or less new things).
Business Operations
Most of the time, if people ask you about your business skills as a product manager, if they’re not asking about how you go to market, then they are thinking of finance or operations and general management.
You’ve probably picked up on the fact that product management has a large operational component, drawing from project management particularly at the tactical product owner / scrum master interface and from program management in the sense of coordination of people and teams, project and resources, to achieve directed complex ambitious goals.
Some of us became UX designers because we like to draw and are happiest when someone else is watching the deadlines and cracking the whip. If that’s you, then product management is likely to feel like all the boring parts of school to you, with no recess.
But if you’re the sort of UX designer who loves facilitating workshops and jumps up to the whiteboard to help facilitate a discussion by helping your colleagues articulate their concerns, or if you’ve tasted the operational and people management aspects of being a design manager and found them to your liking, then you’ll likely take to that “business” aspect of product management readily.
It’s worth noting that all disciplines tend toward people and program management as you rise through the ranks, so in that sense this is less about product managers being business heads and more about management and organizational leadership in general.
Nonetheless, to be taken seriously as a product manager, you will need to demonstrate that you can be organized, that you can keep complicated projects with multiple moving parts aligned and on track, and that you have the communication and people skills needed to motivate and support teams of people as they strive to work together in complex environments.
UX Superpower Alert
A huge aspect of getting things done operationally is stakeholder management. This is another time when interpersonal skills and an ability to understand people comes in handy. Startup founder and user experience, research, and product management consultant Noreen Whysel observes “Your skills that you develop as a UX designer help you to understand the business needs, because you can use the same techniques on the business side, on the stakeholder side, to find out what is it that they need because in a way, they’re a “user” too.
Financial Business Skills
When it comes to finance, though, it’s likely you are treading in an area that never really came up doing UX research, strategy, or design. Because most of the team does not report to a product manager, PMs rarely have profit and loss (P&L) ownership over the product they work on, but even so it behooves a PM to understand what the team is costing the business and what monetary value it is delivering.
Not only does this directly bear on how well the team is performing but it also gives you the PM a heads up if their business unit is a cost center and potentially vulnerable to the winds of change.
Not all product roles deal with transactions or revenue, but doing the job always requires a certain degree of savvy about the money flows through the business and in and out of the product and the team building it. Making the case for a strategic priority is always on some level a competition for scarce resources.
The product manager’s responsibility for cultivating and developing value applies every bit as much to the need to generate literal financial value to the business (or organization) underwriting the code you’re developing and shipping, as it accrues to the customer or end user you’re serving.
For the most part, financial concerns enter the picture in terms of pricing of product and features, revenue models, and the search for profitability. More on that in a few chapters (Chapter 8: Getting the Money)!
Business-to-Business (B2B) Products
Perhaps the product management space that is most steeped in business thinking and business contexts is B2B (business to business, as opposed to B2C for business to consumer, B2G for business to government, and B2B2C for business to business to consumer), meaning businesses whose customers are other businesses. There’s a lot of money to be made selling tools and services businesses need to make their own money. Some have compared this to the Levi Strauss strategy of getting rich selling canvas and tent stakes to gold miners instead of going out to pan for gold directly.
In a B2B context, concepts such as markets and customers shift to become both smaller and less abstract. Sales are made to businesses, not to individuals. The end user is often not the payer (the “customer”), which means that delighting the user will not directly influence their willingness or ability to pay. Also, customers are specific people at specific businesses known to your sales and account management colleagues, not the general public or everyone who can find a Google window, which affects many of your strategies in terms of understanding user behavior, talking to users and customers, and even trying to do statistically valid data analyses (something you’ll hear more about in Chapter 6).
To give a feel for how the role varies when your customers are businesses and not consumers, here is another day in the life of a product manager, in this case from Clement Kao, a product manager at Blend, which makes software for banks. (He is also the author of Breaking into Product Management, and host of one of the best product management communities of practice online, Product Manager HQ).
[Author note to editor: I realize this is very long and will need more editing for concision. Please help! Will update with Clement’s recently published draft in his own newsletter. Also consider including this as an appendix and publishing more as an interview format. Can discuss but for now keep it here.]
A Day in the Life of an Enterprise PM
I wake up around seven. While I’m eating breakfast, I’m looking through Slack, looking through email, just trying to get a pulse of the things I need to be aware about today while I take the time to have a nice slow breakfast before it becomes super hectic. The first 10 minutes of my “workday” is looking through all the calendar events that I have and trying to understand what is my one priority for today.
I think one of the challenges is that because product managers have to do so many different things, it’s easy to be chasing everyone’s randomizing asks of you, instead of thinking about what is the one thing that I absolutely need to get done today to get the ball moving forward.
So that reflection at the start of the day is super helpful to make sure that as I power on through the day and get randomized by people I still have one guiding thing that I’m driving towards. Based on the one thing I’m trying to get done today, are there meetings that I need to move out? Are these things that I actually truly need to do today or can I move them.
Let’s say that for this day, I am trying to better understand a particular set of customers challenges, because I have a feature that I want to get out the door. One of the challenges in B2B is that you don’t get like easy access to your users because you’re gated through the account. Typically in B2C, you can recruit users easily for user testing. It’s relatively straight forward to be able to get people, to look at your stuff.
So one of the things that I have to do right is first make sure that I understand, okay, what is the value proposition that we are going to provide to the project sponsor for that account. Just as an example, let’s say that I’m working with a project sponsor at at a major bank, and I wanted to talk to their users. If I’m going to be burning their user’s time, because they’re trying to run a business, I need to give them a value proposition of why is it valuable for them to expose these users to me. What is the benefit to them? I need to spend time with my account management team before I send off that email off.
“Here are the things that we want to get from your users. This is how much time it’s going to cost you. And here are the benefits of exposing them to us.” How do we want to position this? We also need to make sure that we’re protecting our own account managers, because there’s a longterm relationship that they have with our project sponsor.
We need to make sure that we are empowering our account managers to continue to deepen the relationship rather than have it be super “thrashy.” So there’s typically some amount of lead time needed to figure out how do we want to position this? When’s the right time to bring it up?
In the morning, I might be working with three to four different account managers. All trying to work through what is the objective of this ask that I’m making to their customers and users? What are the things that they’re currently worried about? Do we have a compelling value proposition to get them to expose these people to us as such? We’re all working through game planning of how do we want to reach out to these people and kind of what’s that value proposition opening in front of them.
But on the flip side, the nice thing about having these deeper relationships with these accounts is if there really is a fire they will proactively bring their project sponsors and their end-users’ qualitative feedback to you and say, “There’s a problem. We’re escalating it.” Whereas in B to C, if your user doesn’t like your product, they leave.
To wrap up the meetings with account managers, it’s really important to determine “who, what, and when.” Like, “We agreed you all are writing emails. When will you send them out? And if they haven’t responded back by what timeframe, when are you going to follow up with them?” Just making sure that we’re really clear, how are we prioritizing this? What are the next steps?
Just making sure that we have these different paths laid out, we are all running kind of with the same playbook to make things happen. So, that is a whole morning based on “We’ve we’ve released a feature. We want to understand its behavior. We see the what, in terms of the differences, but we need to know the why. So we, we bring together account managers. Let’s make these asks. Let’s provide this value to our customers. So, that’s a morning.
So now it’s lunch time. This is during the pandemic, and I want to make sure that I have time to myself to reset. I’m going to step away from the computer and make lunch with my significant other. Cooking lunch typically takes like 30 to 40 minutes and then we’ll eat for like 15 and then like, I’ve walk around a little bit, like get back to my desk and then jump right back in.
Now, let’s say there’s a different feature that I own, that I am trying to bring to the finish line. I have this user story, right? I’m trying to empower my user to do X, Y, Z. So by this point I’ve already sat down with design to work through different explorations of how might we tackle this user need.
So today, let’s work through all of the explorations that the designer has come up with and like talk about why it solves the need or why it doesn’t solve the need, which are our preferred paths, as well as any kind of additional constraints to watch out for.
I think one of the things that we have to keep in mind in B2B is that people are using not just your feature, but your entire product to run their business. There are all of these other features that are floating out there, so you can’t for example just optimize for your own retention and engagement and usage because if you just optimize for yourself, you’re going to break other people’s workflows.
From a workflow design perspective, how does this thing fit into all of these different customers’ workflows where maybe your feature came first in the workflow? Maybe it’s in the middle, maybe it’s last. Right. And so you need to like weave that in she’s in inputs and outputs or other even maybe related dependencies. Design has looked across other workflows, and has a sense of like, how might we want to solve for this?
But the other thing that we need to keep in mind is the counter balancing constraints in terms of not just what is the engineering effort, but also in B2B, there are a lot of customer requirements you just have to meet, so the reason why we begin with design is because we’re then going to sit down with engineering and just scale it back. Like, how much work is this ideal design? Where are the rational trade offs that we can make to basically shrink the scope so that we’re going to hit the deadline, but it’s at least like directionally, correct with design?
I think the challenge of doing it the other way, of going to engineering with “what’s the cheapest way to do this?” and then putting it in front of design is that the designer has to wonder “which constraints can I break? If I do this thing, how much more is it going to cost us?”
That can cause a lot of those workflow breakages where we were optimizing for our own speed to delivery and not thinking about “how does this fit into other stuff?” Whereas, if we say this is the ideal design and here’s why this is ideal design, but we know that we’re not going to make it all the way here, engineering, help us roll this back to something that is fixable.
In the future for fast follows, how might we patch in these gaps later to make it work with everything else, knowing that in our very first shot, it’s going to be a little rough around the edges because we’re up against the deadline?
That’s why kind of first design is on the hook to say, how do, how should this thing work? Does it actually meet the user’s needs, not just for this one user story, but kind of across their entire workflow?
Then we need to get design and engineering in the same room. Because I think the challenge is if it’s just engineering that’s looking at it and trying to propose “like. ”We’re going to cut it back this way.” I might say, that’s the one thing you can’t touch because that thing that you’re saying we’re going to change is going to break all of these other mental models.
As we work through, how do we scale this to a deadline that’s going to work, that will basically take like the first half of the afternoon. Have we thought about all of these different scenarios and these different business segments?
Whatever we design and build, when we deliver it to a customer, they don’t just accept it. It’s not like Facebook messenger. It’s not like Instagram, where users might complain, but then they get used to it. There’s no doing that in B2B because they have all these employees that are trained on all of these scripts on all of these like rollout plans.
As the product manager working directly with a lot of these pilot customers, my role is to provide more of the lens of not just what will the user say, but what’s a customer executive going to say when we are proposing this direction or scope or change management.
For the second half of the afternoon,.I’m going to be sitting down with my product operations team to understand, how has the rollout of a past feature been working. How are we seeing the adoption for different customers? We might draw on data, in terms of usage, or we might draw on qualitative account management feedback, like “We are hearing that this account is really struggling with this,” and basically working with product operations to understand for a feature that is in flight how should we fine tune the messaging to make sure that like our customers can adopt it.
Or if I’m trying to release a feature that’s already been built, I’ll work with product operations on the game plan. Who needs to know that the feature exists and what is its value proposition? How are we going to make sure that customers get why they should use this, and how they should train up, and how we are going to organize ourselves to make it happen? We need to go in and configure their stuff and make sure that they’re trained, to make sure they don’t have complaints.
We worked through their legal compliance teams and their training teams and their business teams before we promote to production. Now, I’ll be sitting down with product operations to come up with a game plan of when do we need to communicate out that this feature exists internally so that everyone is trained on. Here’s the value proposition. Here’s why we’re doing it. Just how much it’s going to cost. Here’s how it’s prioritize against all the other things that we’re trying to release. And then here are the external comms of this thing is now available.
Because again, it’s not just like I ship it and then watch the data flow in. I need to train all my internal stakeholders first. “This is what this does. This is how it works. And don’t turn these other things on because they’re currently in progress. And if you turn them on and stuff will break.”
Let’s say I want to release some particular feature. Ops might say, well, right now all of our customers are currently trying to adopt this other thing. And like that thing is going to take all of this bandwidth, and so we cannot release it right now, as much as you want to. Because it’s going to cause a lot of thrash and like teams are not ready to take them on.
Also, our customers have limited bandwidth to use our product and to train around our product because they don’t just use us. They use dozens of other software vendors, and they have hundreds of other processes that they’re running all the time. And they have a project management team, they have a program management team and that team has its own bandwidth and staffing. And so sometimes we need to, we need to figure out like, okay, well we need to get in line.
So we are in the late afternoon now, and there is some customer reporting there is an urgent thing that is broken. They’re freaking out about it and they need someone to take a look. So what I will first do is I will first jump in to understand it.
Do we have enough information from the customer to actually know what are we are supposed to do from an engineering perspective? Because if someone just says it’s broken, it’s like, Right. What’s broken? How do you reproduce it? Like under what conditions? I think the other thing that’s also really challenging is that, you know, when you are shipping enterprise products, there are so many different like configurations that businesses need that they wind up in all of these different states, all of these different combinations.
So, if you see that some set of customers are reporting a bug, but the other set aren’t, that’s a hypothesis. It’s probably some configuration that’s common to these that’s causing the problem. So we really need to understand which customer reported it, which of their users reported it because they have different roles.
Typically what happens is like an end user will freak out and they’ll ping our support team and then our support team will raise the ticket to product after going through standard support processes. So it’s my turn to intervene, to look into how did this happen? What is the breadth of impact? Who’s being impacted? If I staff engineers against it too early, they’re going to say I don’t have enough information.
And when some problems manifest themselves, after you do some more digging, it’s actually sitting on another team, because like there are internal dependencies on making this workflow work. So another part of my job is not just indiscriminately asking my engineering team to attack it with their subject-matter expertise. It’s actually understanding where in the stack is this.If it’s not mine, I route it to a different product manager who knows what this thing is. Right. So there is some amount of that like internal coordination of, okay, we now have enough information from the customer to know what’s going on. We also have enough information to have a guess of probably where in the stack, the set so that we can route it to the right team.
So we send it to the wrong team. They’re going to burn a bunch of cycles, kind of like not getting anywhere. That’s what’s important that we wrote that. Do you ever have to, is there an element of having to persuade or lobby for a counterpart to prioritize, fixing the thing that’s breaking your flow, but it’s dependent on their implementation?
I sent it over to engineering. We spin up a zoom “war room” and we start working through the triage together until we figure it out, till we have a fix. When we know how we’re going to hot fix it, we’re going to figure out the release plan.
This is like a longest day because there’s a production fire. So let’s say dinner’s going to be at 8:00 PM instead of like standard 6:00 PM. I need to go loop in legal compliance, an InfoSec (information security) on my my side, to make sure we understand the impacts of the bug and the fix, because sometimes the fix might actually cause even more problems.
Then, assembling our internal communication. While engineering is still working through how to that we’re going to release the fix, it’s my job to figure out how are we going to release the communications?
Usually, looping in the account managers that are affected and saying, this is what happened. Here’s how many people were impacted by this thing that had happened. Here’s the time when we expect for these things to go out. So that, that way you can tell your customers like this is when this thing is going to happen.
Oh, and not within this particular day, but a thing that will happen in B2B is I will later be on the hook to provide a root-cause analysis to customers of why did this happen? And a detailed timeline of how the bug was introduced, how it was resolved and what are we going to do to fix it in the future.
We’ve got the communications, we’re all good. The fire has died, then I get to separate from the computer. I think one of the things that helps is to look back on the day before I step away, and ask “ Did I do the thing that I said I wanted to get done today, early in the morning?” and if not, making sure that I understand, how does this change? The rest of my initiatives for the rest of this week, or like, are there things that I now need to reorder based on what has happened today? One of the things that I was able to accelerate or the things that I have to like push back, um, so that I’m kind of like understanding what my future workflow is going to look like.
Then from there my day ends. I make dinner with my significant other, we go out for a walk to digest dinner and then, we spend the rest of the night, like not looking at Slack. Yeah, that was a busy day!
Key Insights
- Business is nor a dirty word.
- Product is responsible for building value both for customers and for the organization, so that it may sustain itself
- Product management demands deep understanding of a target market and a solid strategy for how to capture a percentage of it.
- For a new product, achieving “product-market fit” is job one and until you have it, time spent adding features or polishing bugs is wasted.
- Great product managers are obsessed with their customers (both past, present, and future) and ravenous for any morsel of insight into them.
- Some product managers are better at launching products and others are better at bringing out the best in existing products.
- People and program management are a huge part of product and get to be moreso as you rise to leadership.
- Business also means money, and more about that later.
—
You can sign up to be notified when Product Management for UX People is available for order at Rosenfeld Media.
