Tell me if you’ve heard this one before: You’re approached by a prospective client or department head who believes wholeheartedly that they know what their problem is, and what specific set of software features will solve it. After doing just a smidgen of discovery, you find out what you suspected from the start–the problem isn’t quite so clear, and the solution isn’t quite that simple. Maybe it’s an executive just following their gut, or maybe like a schoolkid with a crush they’re an organization mimicking the interests of their lov–I mean competitors. Either way, they haven’t done the analysis necessary to understand the problems truly facing their organization. Either way, it’s your job to tell them they’re wrong. Right?
Well, maybe.
Arriving at a mutually beneficial outcome in these situations starts at the beginning, with a mutual understanding of what a product is. So, what is a product?
Many organizations might have an answer for that, stored deep in a nicely branded product practices powerpoint that sounds like it’s lifted directly from the “Agile” software development textbook, if there were such a thing: “A product is a collection of features organized around a central theme designed to help users achieve a desired outcome.”
But those of us who work in a real world that doesn’t always play by textbook definitions know that a product begins to take shape even earlier than that, before features and story maps, before infrastructure and release plans. To people who understand that before you can build the thing right, you have to first be building the right thing, a product is as simple as a solution to a problem faced by a group of people working toward a shared goal.
“If I had asked people what they wanted, they would have said faster horses.” - Henry Ford
1. Frame the problem
Your first hurdle might not have anything to do with the problem itself, but a condition common to all organizations - communication. How does your customer’s organization communicate that a problem exists? Who has power to make the decisions that actually solve problems? If it isn’t someone who is (prospectively) going to be using a solution you help design for them, then said solution might be destined to fail before you’ve even decided what your infrastructure strategy will be. All that design effort would be wasted on an ecosystem that isn’t even prepared to be transformed in the analog world, nevermind the digital one.
“We currently don’t have any software to support our order intake process” isn’t a correctly framed problem, at least not one a seasoned PM is interested in solving.
A better framing might be be: “We are making too many errors in our manual order intake process, and fixing them is costing us $X.”
Getting to know how your customers frame their internal problems can help weed out some problems at the root, before you end up spending time and money building expensive solutions that aren’t going to change the way an organization thinks and acts from the top down. Problems are often organizational before they are operational - and we are problem solvers first. Software might not be the solution for every organization, at least not at first.
1. Understand the problem (and be able to communicate it effectively to decision makers)
“Remember: when people tell you something’s wrong or doesn’t work for them, they are almost always right. When they tell you exactly what they think is wrong and how to fix it, they are almost always wrong.” - Neil Gaiman
The order intake process problem isn’t purely hypothetical. Once, a client came to us, as many do, thinking they were buying software. “We need you to automate our ordering process. Scrape emails, build a robot and some work queues, poof. Magic. Right?
“Well, if you don’t mind,” we said, “could we talk to some folks on your operations floor?”
It didn’t take long to find out that the effort to achieve any level of automation was going to be gargantuan and clouded with uncertainty. And we discovered something else that they hadn’t realized they’d be losing - the face-to-face, personal relationships between operations folks and their most loyal returning customers. If we hadn’t dug deeper, we would never have known the real cost of assuming we knew what the best solution was.
Because the problem isn’t just about definitions - it’s about identifying pains and investigating root causes. Users don’t always have the language necessary to convey a complete picture. Executives don’t always have a crystal ball view into all of the places where their organization is extracting value. That’s a space where mature product development teams should thrive.
3. Sell the solution
When we fix a client pain point, we’re not just doing it to be benevolent. We’re doing it because someone has set a goal to fulfill and we are responsible to help them accomplish it. They’ve sought our help because they want to retain some value lost through an inefficiency, and we know the knowledge and skills we possess have great value. If you’ve correctly framed and understood their problem, your customer should already know that helping users work more effectively also gets the business what it wants. This is where speaking the business’s language–not just dollars and cents, remember, but understanding who they are and why they do what they do–begins to really matter.
You know who your client is. You know what they value. Once you’ve done the analysis, the research, and the solutioning, the last step left is to synthesize the “What” of the thing you’re building with the “Who” of your customer. This requires digging a little deeper, not just knowing what they do–move things, make things, sell things–but why they do it.
A few years back, I was helping a property management company modernize their maintenance processes – essentially, helping them route repairmen to homes more effectively. The solution was pedestrian. It’s been done before, and it or something like it will be done a hundred times over by a hundred other companies. The thing that made them trust my team over any of the other consultants is best summed up by something their primary stakeholder said on a call after we’d walked them through an analysis of their current process, and proposed a new one.
“I think what impresses me most is that you just seem to get us.”
There it is: You understand what we’re trying to do, you know why we do it, and what’s more, you see the people behind the process.
That’s the most important thing I’ll ever hear from someone I help build something for. It’s the PM’s mantra, and if it’s not I think it should be - I get you. We’re on the same team. You’re in safe hands. It’s that kind of trust between users and technology that spans the chasm between designing a good product and building a lasting legacy.