In enterprise software, most product managers (PMs) are drilled in the importance of user research and listening to stakeholders. They’ll cite this as the way to navigate ambiguity. They’ll use it as a trump card in arguments. In user and stakeholder requests they’ll see their guiding light toward the product’s north star.
They’re not wrong. If we’re not building products for users then for whom are we building? Stakeholders provide crucial user insights and highlight key business considerations.
Solving needs and simplifying experiences
The problem is that most PMs will literally translate user requirements and existing workflows into features in their applications. For example, Figma users at some point must have requested a collaborative space to brainstorm ideas before putting the proverbial pen to paper on designs. Hence, FigJam was born: an entirely new surface and feature set in the Figma application that enables people to…well…draw boxes and arrows and post sticky notes. Not so different from a blank design file, only without the ability to actually create designs in the same place.
This was - in my opinion - a waste of engineering resources (development and maintenance) that resulted in a clunky user experience. So what happened? Most probably, somewhere along the way someone transcribed a user request, verbatim, and turned it into a feature. And what’s bad about that? After all, the user expressed a need, and the PM delivered exactly what they asked for. Well, that’s not the PM’s job, and we would never get any good products that way. A good product not only solves the user’s needs but also simplifies their life. Making a new class of visual collaboration file (in an app whose existing core feature is visual collaboration) does the former but not the latter. Google doesn’t give me spreadsheets for when I want to make a real financial model and “jamsheets” for when I want to brainstorm modeling approaches. They just give me sheets.
Avoiding literal translation of user requests into features is not a new concept for many PMs. Some will quote Henry Ford, who said that if asked how they would improve transportation, people would have requested “a faster horse” - not a car. Others will invoke Steve Jobs, who ignored Blackberry users’ desire for a larger keyboard and instead designed a touch-screen for the iPhone. Both innovators solved customer pain points while also markedly simplifying users’ lives. Yet even those PMs who are aware of these examples struggle to achieve both objectives in their own work.
The importance of abstraction
This brings us to the most important tool in the PM’s toolkit: abstraction. The PM’s job is not unlike that of a theoretical physicist, trying to come up with a theory that elegantly explains many phenomena. Doing so requires abstracting observations into generalized principles that are broadly applicable and simplify our understanding of the world. Newton understood that the falling apple and planetary motion are bound by the same force, and put together a simple, generally applicable formula for the force of gravity. By the same token, a good PM will unify various user needs into simple, generalizable experiences.
Once you realize the power of abstraction, you notice it in all the most successful products. On Twitter (X), everything is just a tweet, no matter the format, content type, topic, author - there is no separate surface for fun tweets vs serious tweets, news tweets vs sports tweets, or any other distinction that may be important to users. In other words, attributes such as content type or topic are abstracted away, resulting in an extremely powerful experience whereby readers can discover anything without needing to know what they’re looking for upfront, and authors can post anything without needing to specify where it will go. Now you have a world of information at your fingertips (and can still add precision through trends, tags and other filters).
Similarly, everything on YouTube is a video, everything on Instagram is a post, everything on Addepar is a node in a financial graph. In Henry Ford’s world, the genius of the car is that it doesn’t care who’s traveling, where they’re going, or what they’re carrying with them - it gets them from point A to B in a highly efficient way. For Steve Jobs, the abstraction was that every interaction is a touch on the screen, whether scrolling through news, playing a game, or typing a message - the keyboard appears dynamically within the same framework as everything else. These abstractions make great products, by enabling user experiences that are both extremely useful and extraordinarily simple.
At Opto, our product team is tasked with identifying opportunities for abstraction. This is especially important in our domain, where we build software for complex financial analysis and investment workflows, in a part of an investment landscape (private markets) with no established software patterns.
The temptation to translate user requests and stakeholder requirements verbatim into app experiences is significant, because it’s hard to imagine a world where things work differently - doing so requires abstracting workflows and processes into generalizable concepts, in a domain where no such concepts currently exist. At Opto, we’ve been asked many times to create different experiences for different types of private assets, investors, investment firms, diligence and compliance processes…the list goes on. Indeed, the data types, business logic, and user personas involved are wide and varied. Using abstraction, however, allows us to build broad infrastructure for private markets investing that works - efficiently and simply - for different cases. And just like with other best-in-class products, that’s how we best serve our users.
For disclaimers, visit https://www.optoinvest.com/disclaimers.