Are requirements really simple?

Which is the most simple product you use on a daily basis?

For me, its the wrist watch. I have several analog quartz watches which I use depending on occasions. Some of them show just time, some of them Date and Day, while one is a chronograph (i.e. it has the function of stopwatch).

In this article, I put forth my thoughts on 'simple' asks from a user's perspective. At the same time, I highlight the dilemmas a product manager has to endure when considering adding a simple feature to a product. In my next article, I plan to present the framework that I have started using in my decisions.

Simplicity?

How do common middle-class users like us, base our decision of buying a watch? For me, its generally the looks and to certain extent, functions like Date and Chronograph. That's a justified expectation. That's what the norm is.

But do you know how exponential the complexity becomes as we keep adding more functions?

For example: A simple time showing Quartz watch has about 50 moving parts, where as, if we add a simple Chronograph to it, the moving parts increases by about 10 to 15 more parts. This is not just 30% increase in complexity! You should consider the number of interactions these parts would have with each of the other pre-existing 50 parts and and how those parts would be impacted because of introduction of these new ones.

Phew! So in order to give a reliable time and a stopwatch, there is a ton of complexity behind the scene. All the parts have to work perfectly all the time.

But the question is - is that justifiable?

We as users sometimes fail to realize how complex our everyday gadgets work - simply because are supposed to work flawlessly as per our experience and expectations

From user's perspective

Many everyday products successfully hide their complexities. Take example of the HDMI cable that I am using. There are so many varieties of HDMI protocols and the hardware should be able to handle all of them.

We as user, can see and experience what the product can do and what its capable of - we don't fully understand, but often fail to comprehend the effort that went into creating it so that it works reliably. What users see is the tip of the iceberg

From Product Manager's perspective

Let's look at it from product team's side. In B2B products, where every business asks for a feature / customization suitable to their business, even a simple outcome for end-user involves a ton of back-end complexity.

Behind the scenes, the product manager has to perform a series of activities even to launch a single feature: do the research, find the one problem worth building a solution for, consider many possible alternatives, discuss with architects, settle on the final solution, convince stakeholders and create a friction-less experience while making the application reliable and performant on a scale.

PMs also wiggle, especially on scope, time and resource. We cut corners, put things on roadmaps and do experiments. And here I am stuck to find an answer:

What is the acceptable compromise in terms of technical debt, user experience and scalability?

Finding the balance is the art of a PM and is personal to every individual. And a PM is always running against time, and thus is prone to shipping a sub-optimal product. If this happens, every new sub-optimal feature adds to the complexity of the overall product. And if shipping sub-optimal solutions become a pattern, we would be burdened by huge technical debt.

Examples of hidden part of the Iceberg

In my practice, I have come across numerous requests which seems to be trivial on the surface, but in order to implement it, the product has to introduce significant technical challenges.

One example is: Can product bring the 'Reminder Tasks' from the present tab on product to XYZ tab, where the user can see the Reminders(if present) against each job.

Prima facie, this seems to be a genuine ask, but its technical implementation on product side has significant uphill tasks. Integrating two different workflows introduces N number of Ifs/Else, each of which have to be calculated by the product manager

Another example is Slack. If you use Slack, you might be familiar with how its messaging notifications work. If you mute a channel, you won’t get notifications from that discussion channel. If you activate “do not disturb” or manually pause notifications, all notifications will be muted then. Let us see the user facing config screen for notification

What looks logically simple for the end user turns out to be a complex flow of decisions and nodes for the product manager. As users, we see the above screen, whereas as PM, we see the below one

What goes on below the surface?

So what are some 'Behind the screen' activities that a product manager endeavors? The voyage starts with:

Validating the ask: Is there a genuine user case? Talking with other customers to understand the primary pain point. Even if its a genuine user pain point, does it translate into a business case worth solving for?

Prioritizing: Depending on whether a PM is in B2B vs B2C market, the steps in this process would be different. But at the end of it, depending on the pressure from various stakeholders, on the criticality of situation, availability of resources, technical prerequisites and the value of ask, a PM has to prioritize a requirement among hundreds of others.

Solutioning: A PM has to focus in order to come up with solutions. Getting even half an hour of focus time is sometimes is a stretch. And then investing hours to understand the impact, technical feasibility and retro-fit plan. This is where the balancing art of a PM comes into play - and is one of the most important skill a PM can hone. A PM has to juggle and balance the complexity of the probable solution, the crowdedness of existing interface, the current technical debt, architectural complexity or the omnipresent internal knowledge gap.

Documentation: Imagine writing a One-page essay after every button, checkbox, input field, and other interactive element your product/feature has. How many pages would you end up with? This roughly illustrates how much communication and documentation a product manager and the rest of the organization need to do when documenting, announcing, selling, and supporting a solution.

Project Management: Then comes managing the stakeholders. Convincing the stakeholders on the solution and approach, managing roadmap and ETA, training customer support, sales and consulting team, etc.

Other Risks: User adaption, user satisfaction, impact on metrics, etc are some risks which the product manager has to take into consideration. All these come into play because of practical user behavior and expectations. For example, in my product if I provide search capability on a particular parameter, the time taken to produce result would increase by 15%! Which is huge considering that we add just one more parameter. But do my wider user base really need that parameter to be searched? Would they be fine to accommodate slight perceivable delay in search result? How would it impact the overall experience?

So that's all I have to say in this article. I have gone through how we, as end user, take reliability and simplicity for granted. Then we understood that what seems to be simple, a tip of the iceberg, turns out to be a major undertaking for the product manager.

In my next article, I will introduce you to my thought process on how I take decisions. Feel free to comment and share.