Getting business product management wrong
I recently discovered that a problem I’d previously worked on was wrong. Not just wrong, but wrong by an order of magnitude. I didn’t discover this from user testing or feedback, or any of the ways product managers might expect to validate some work or hypotheses. I discovered this from coming across a completely different solution to the same problem, created by a completely different team.
We had undertaken a rigorous discovery process, understood the problem space deeply, prototyped and iterated on potential solutions, worked with various end users to test our hypotheses. Textbook product discovery. All of that is still true and I wouldn’t have changed our process in retrospect. But it’s clear now that we had taken a wrong turn somewhere and hadn’t arrived at the “best” solution. What went wrong?
We had a product that helped people track film and television productions. Our customers, individual studios working on a production (or several) would effectively create a database for the different pieces of data they were interested in and bring their teams in to collaborate.
The specific problem that we were looking to address at the time was that our users were working with data in the database but needed to be able to produce a number of different reports. Our research showed that, for the most part, different studios were looking to understand the same things, and essentially to create the same set of reports. The challenge we faced was that no two databases were really alike, so there was no easy way for us to just generate those reports within the product. This was the problem statement I came up with:
It’s hard to meaningfully find information around the progress of work of the creative progress in production, in part because that progress is defined and captured differently by individual studios.
My hypothesis then was that if we could help users normalise their data, we could feed that into a set of turnkey reports. The user would need to put some effort into the normalisation process, but then they would get a set of well-designed reports with no extra effort, on an ongoing basis. We validated that hypothesis and iterated towards a solution.
What was good about this approach:
- It was a more guided experience, and easier for people to understand how to progress
- The setup only needed to be done once, and so in the long term it took users much less time to complete than their current workflow
- Reports would be consistent and look great no matter who was producing them
I think though, that while the hypothesis was correct, my mistake was that it was the wrong hypothesis to begin with.
The alternative solution I saw was to meet users where they already were. Rather than directly solving the problem, they gave the user the tools to go solve the problem themselves. How they did this was to look at how users were already solving the problem (copying data into a spreadsheet and then editing and formatting it there), and then bringing that experience into the product and streamlining it (work in a spreadsheet but able to access the live data in functions etc).
Although this didn’t have all the benefits of our approach, it did mean that:
- People’s existing workflows didn’t fundamentally need to change
- It was more flexible: rather than relying on our own assumptions (based on research, but still) about the data the reports needed to have (and how they should be presented), those aspects could be changed as needed. For example, users could simply round-trip their data through other spreadsheet applications to perform more specialised tasks
- It actually solved a set of completely unrelated problems with our product (for example, creating new fields in a database has a set of associated performance and user experience costs, whereas this solution allowed for basically arbitrary rows, columns and cells to be included on a given report without affecting anything else)
So, the question I’ve been wrestling with, is what could I and my team done differently to arrive at (or at the very least, consider) a similar solution?
When I try to evaluate the two different solutions, what stands out is that one tries to solve a problem for users completely, and the other gives users tools to solve problems themselves. For lack of better terminology, I’ll refer to the former approach as a specialised solution, and the latter as a generalised solution.
Neither is inherently better than the other. Specialised solutions seem to require more assumptions and therefore bundled business logic and guardrails, generalised solutions require more effort on the part of the user but provide a greater range of possible outputs.
When I try to think of some examples, they are things like Turbotax vs Excel, Pinterest vs OneNote, Instagram vs Photoshop, TikTok vs Final Cut Pro, Nest vs Kibana, smartphone cameras vs SLR. One pattern that seems to emerge is consumer vs business.
Hypothesis: Specialised solutions are preferable for consumer products
Hypothesis: Generalised solutions are preferable for business products
Why would this be the case though?
One theory I have is that edge cases matter a lot more in the business space. For example, imagine a product that lets you compose and present a document that is automatically translated depending on the viewer’s native language. To reduce complexity, the documents are all self-contained in the product ecosystem (ie the Cloud). Both consumers and business users alike might have need to gain access to the document, but an evaluation of those needs might reveal them to be edge cases (“I want to feel like I have ownership of my data”, or “We have auditing requirements that require access to those documents”), and a product team would justifiably deprioritise them.
But here’s the thing– consumers may be able to live with the limitations, but in many cases businesses can’t, resulting in a frustrating or even unusable product. For them, a competing solution that requires separate translation would be seen as superior, even though it requires a more convoluted workflow (and is perhaps an outcome the competing product team was completely unaware of).
Hypothesis: It matters more for a business user to be able to achieve a desired outcome than for a consumer user
The flipside of all this is that in order for a product to be accessible, it needs to offer a more controlled experience. For example, iOS is easier to learn than Windows because it imposes tighter control over the user experience– this results in iOS applications having more in common than each other than Windows applications can. In this case, the trade-off mostly works: there are a whole host of things iOS can’t do that Windows users can, but on the other hand iOS is much easier to figure out how to do the things it can do.
Hypothesis: Generalised solutions are inherently harder to learn than specialised ones
Of course, this isn’t really a binary state. Even with the specialised consumer-focused products I listed earlier, there’s a degree of flexibility afforded to users, and good business products should at least strive for a user experience that guides users to success. For example, there’s probably very little to be gained by having users learn a new way to perform common actions like access menu items or browse for files. But imagine if all business desktop applications were subject to the same Human Interface Guidelines as iOS– many business use cases would become limited or break down completely.
So where does this leave us? Well, all the hypotheses I listed are (currently) untested, so ideally I’d start there. But beyond that, this is what I’d try to do differently next time (in business contexts):
- Look for solutions that aim to complement rather than replace existing workflows
- Provide an experience that guide users towards a range of possible outputs, rather than a single one
- Where there’s a trade-off between supporting different edge cases and reducing effort on the part of the user, favour the edge cases