In my last post, I talked about what Product Management is (and isn’t) at a high level. As it turns out, PMs do many things and provide a lot of context, but one of PM’s core functions is to provide guidance on what to build. Whether you call it requirements, user stories, market problems, features or whatever, the main idea is that the PMs specify the what, and the engineers figure out the how. In this article I’ll discuss some important but non-obvious aspects of performing this core PM work successfully.
Let’s start by defining what this guidance looks like. In general, it is good practice for PMs to actually write something down that will help Engineering understand what is needed. Writing things down helps with accuracy, tracking, and accountability. PMs generally like to create a number of discrete, standalone writeups that can then be combined and assembled in various ways into projects or releases. I like to call each of these writeups a “Market Problem” as opposed to a requirement, user story, or feature. In my mind, as a PM my job is to figure out what challenges my potential customers have – what prevents them from doing their jobs efficiently, from being entertained, from keeping their ice cream cold … whatever. I call this a Market Problem because it’s a problem that my target market experiences, and that I think we can help solve. I generally see other terms―features, requirements, specifications, user stories, etc―as being subcomponents of solving an overall problem within the market.
That said, as an aside I’ll note that my “market” is not always paying customers. In the PM world, we generally speak about the persona of the customer we are selling to: a so-called Buyer Persona. But you will also want to consider solving challenges within your product for other personas. For consumer products, usually the buyer is also the user, but this is not necessarily true for B2B products. Also, successful products have other needs, such as vendor management features, low cost operations, and so on. Here are a few examples of Market Problems that aren’t aimed at the actual buyer:
- Ease of use: although making a product easy to use may help a sale (because a demo or trial shows better), the real beneficiary of ease of use improvements is the end user who actually has to sit in front of the thing all day long. Sometimes end users get to evaluate products before purchase, but other times companies will buy products solely based on how many feature checkboxes they meet, regardless of whether those features are actually usable.
- Support logins: A buyer likely won’t know this feature even exists until they need it, but giving a customer the ability to temporarily grant a user-equivalent login to their specific product instance helps your Tech Support team reduce their support costs.
- Backend refactoring: I’ve worked on many projects where Engineering spent time re-organizing a product’s backend database―something the buyer may never notice, but that allowed us to reduce hosting costs, speed up queries, and lay foundations for future improvements.
Find The Why
If you aren’t careful, you may spend a lot of time building a feature that a customer asked for, only to have it fall flat and not really meet their needs. Or you might find that it creates a never-ending cycle of “now that you’ve built that bit, can you extend it by…” These are symptoms of PMs that haven’t really understood WHY a customer wants a specific feature.
Humans have a natural tendency to try to come up with solutions for problems on their own. Thus you will often come across customers that basically tell you how to design and engineer your product for you. This can be a good thing, but as the PM you have to take all that advice in context. You also need to spend some time, if possible, and ask pointed questions of the customer to find out why they want specific changes to be made. Time and time again I have had customers ask for things, and after some questions we realized that (a) a parallel feature that meets their needs already exists or (b) a different implementation than what they had in mind would still meet their need, but be more powerful or work better with other product features. Here are a couple of examples:
Example 1: For one of my products, a security agent is deployed to various desktop systems, Windows and Macs, and the agent would collect certain information from the host: hostname, IP address, operating system, etc. You could then look at a list of devices with the accompanying info in the product UI. I had a customer that asked me to add the device serial number to that info. After some research I discovered that the serial number isn’t always set for all devices, because some OEM vendors don’t use it or for other reasons. So I started to suggest other options for unique identifiers for this customer’s systems. After some discussion, I finally asked why the serial number was so important, only to have them tell me that it was because their asset management system used the serial number as its unique identifier, and they wanted the two systems to match.
Example 2: One of my products was released with a set of amazing interactive reports; you could click on nearly any element and filter or drill down via your selection. We thought this was all we’d need to satisfy any customer’s reporting needs. I then had a customer ask me for CSV export of that same data, so that they could “generate reports.” After lengthy discussions about what kinds of reports they needed and could/should we build them on the existing interactive report system, we finally asked why they needed the data in CSV form. We found out that they intended to import the CSV files into a database and join my product’s data against data from third-party systems―something our interactive reports could never do.
How Big is a Market Problem?
One of the things that junior PMs struggle with is how to properly size Market Problems. This is a real challenge, because Market Problems need to be (a) small enough that Engineering can solve them in a reasonable amount of time, and (b) actually solve a real problem. Where PMs tend to get into trouble is in one of two ways: either they identify a small sub-feature that only partly solves a problem, or they identify some huge challenge that they don’t define well, and that keeps growing in scope (so-called “scope creep”). A good Market Problem writeup will identify a specific real challenge that existing customers and prospects (or other stakeholders) face , that can be fully resolved via a chunk of engineering and development time, and that has a clear end point.
You may have seen the classic “user story” writeup template, that goes “As a …, I need to … or else I can’t …” This is a decent way to state a Market Problem, but it’s also easy to get too far down in the weeds. Imagine for example that your customers need to be able to create new users within your product. The obvious Market Problem here is just that: they need to be able to create users. Don’t be tempted to create a Market Problem that’s about the database changes that need to be made to support new users, then one for the user interface changes that need to be made, and so on. It is Engineering’s job to figure out which product components need to change to solve the Market Problem overall. I have seen way too many Market Problems of the form “As a user, I need the backend user database (which I never see) to have a column to track the last login date.” That’s not a Market Problem statement, that’s engineering instructions. Think about flipping that to something of the form “As a security administrator, I need to be able to run a report that shows me the latest time any individual logged into the system. Otherwise I cannot satisfy compliance requirement X that is needed for PCI compliance.”
Conversely, avoid Market Problems that sound like “As a user, I need a bunch of reports in the system.” As a PM, it’s your job to go figure out which reports, and how those reports will be used and therefore what data should be shown on them. The Market Problem should list the specific reports needed along with their purpose. If you can specify more details such as specific data points or display techniques, all the better. Engineering may change these, but if they know what the purpose of the report is and can come up with a better way to solve the problem then everyone will be happy.
Also note that some Market Problems are just too uncertain, unknown, or large to really know what to do with them. It’s also OK to kick off Engineering research projects to look into some part of a Market Problem to see where a solution might be found. These efforts are a little different than a classic agile Market Problem, as you tend to just constrain them by time (i.e. “spend 40 hours researching how to do X”). If results indicate as such, you can figure out if you want to invest in further research or if you have enough info to build a full Market Problem.
Writing Good Problem Statements
Your ability to write good problem statements is going to be important, as it is your primary tool for communicating what is needed to your Engineering team. You can find all sorts of templates and story structures and whatnot, but I have found that really the most important pieces are:
- Clearly state what the real problem is and how it affects the user’s life
- Clearly state what a good solution to the problem might look like
- State any additional constraints or requirements.
The first part here is all about talking to your customers and understanding at a deep level what kind of challenges they face. In PM-land we always hear “the answer to your problem is not inside the building,” by which we mean get out and talk to your customers. People LOVE to complain, and if you have a sympathetic ear they’ll tell you everything you need to know. Then you need to translate that into something concrete and definite that Engineering can also understand. Note that you may have to overcome some inertia, “but that’s not how the product works,” or similar (more on this below). As long as you understand your product and the customer’s challenge well, you should be able to explain the problem.
The second part of the statement should be about what a good solution might look like. This is a lot about brainstorming ideas with your customers, peers, product leaders, etc. But approach this with a lot of humility, the solution that may seem obvious to you may not be the correct one. The goal here is not to tell Engineering HOW to solve it, but just to demonstrate what one possible solution might look like from among the universe of possible solutions. You can make sketches, diagrams, or edit screenshots to show what you want, but again make it clear that what you are presenting is just possible options.
And lastly, stating specific requirements or constraints can be important, depending on the Market Problem. A fancy new way to query the database is cool, but not if it takes four hours for results to come back. State up front what kind of performance, size, cost, etc you are willing to consider so that Engineering knows what constraints they are working under. They can always come back to say “not possible” and propose an alternative, but they need to understand the user expectations of what a solution looks like.
Once a Market Problem is written down, I highly encourage you to sit down with your Engineering leaders and walk them through what you’ve written. In my own work, I would hold such a meeting and then I would create a wiki page (for larger problems) where Engineering and I would maintain a Q&A back-and-forth on their questions, my answers, additional constraints or requests as they came up, etc. Requirements change, plans change, new ideas arise, so it’s always good to make sure you start from a consensus and then evolve from there.
An Example
Here’s an example that shows some of the potential pitfalls of not really understanding or communicating the “WHY” behind a Market Problem. I was first brought on to a team that owned an email security product midway through a project to add encrypted email to the solution. You know the idea: Alice wants to send Bob an email, but wants to make sure that Bob and only Bob can receive the email and read it. Bob in turn also needs assurance that Alice is the real sender. At the time, this challenge had already been “solved” in the consumer space with e.g. PGP, but required cumbersome key exchanges between individuals. There weren’t many good corporate solutions that would generally work for any company trying to communicate to its customers.
So the PM at the time wrote up the problem (pretty much as you see above, with several extensions) and sent it off to Engineering. And Engineering came up with a slick solution that would capture the encrypted email as it was sent from the corporate client, re-route it off to a portal, and then send the recipient a separate email inviting them to come to the portal to see their email (after appropriate identity verification). This wasn’t end-to-end encrypted email, exactly, but it was a way to get the recipient into a secure encrypted environment within which they could communicate with the corporate client.
Which was all well and good, but after we shipped it not many customers actually used it. We sat around scratching our heads for a while, and then starting asking why. It turned out that our problem statements had not clearly identified the personas that were involved in the Market Problem, and the WHY behind all this encrypted email business. In particular, we completely missed that the whole goal of this was to provide assurance that Alice (our corporate client) was talking to Bob (their customer) and vice versa. We gave Bob a secure encrypted environment, but we didn’t actually solve the challenge of making Bob feel safe and comfortable connecting to that environment: the “portal invite” email he received didn’t have anything that identified it as coming from the corporate client he was doing business with! Imagine you are working with Secure Bank, and one day you get an email from some Random Email Company that says, with no branding and not from securebank.com, “hey, come log in to this portal!” Would you click on it?
As you can imagine, we had to quickly add client branding and client sender addressing to the portal invite emails, and that solved the problem. This highlights the challenges that can come into play when PMs don’t fully think through a Market Problem, consider the personas involved, and consider the WHY behind the feature they are building. “Encrypted email” is not a Market Problem, it’s just a feature that solves the problem of two parties’ need to communicate securely and privately.
Things NOT To Do
I’m going to wrap this up with two other bits of advice about Market Problems. I’ve already alluded to both of these, but they’re worth expanding on separately:
First, as a PM try your hardest not to try to actually solve the problem you have identified. There’s a reason that those folks that write code are called Engineering or Development and not “Software Monkeys.” No matter how awesome you are, they know how the product works better than you do. State the problem, explain one or more POSSIBLE solutions, even sketch some options, but always position such solutions as possibilities, not “go build it this way.” Then be open if they suggest alternate approaches to solving the Market Problem. Taking this approach will go a long way to producing better products and ensuring that your Engineering team has a good relationship with you.
Second, once a Market Problem is fully specified and aligned with Engineering, then comes the point where Engineering needs to estimate the cost of delivering a solution for that Market Problem. This is a normal part of agile development, and a good practice so that you have SOME predictability as to when features will actually be delivered. That said, don’t take (or let Engineering take) too long to do this. If they know exactly what it will take, they’ll come back with a number quickly. If they are uncertain or unclear, then either you need to sit down with Engineering to go over the Market Problem again (maybe they don’t fully understand the challenge, what solutions look like, or the constraints), or they might need to go off and do some research before they can estimate. In the latter case, just add a block of research time to the next sprint, get the results, and then revisit – don’t try to squeeze the research and the Market Problem implementation into the same sprint. Engineering estimates are just Scientific Wild-Ass Guesses (SWAGs), do not fall into the trap of consuming a ton of Engineering time just trying to come up with “accurate” estimates.