How Products Are Built..
In the world of ever changing needs, our requirements keep adding every day. How does a Product Manager address so many demands in one sprint/quarter/cycle? To understand it, let’s take a step back and decipher what helps in building a product. It’s technology!
Of course, I’ll be a generation late if I say that the motor of the world is being fueled by “technology” but definitely too early if I say that we have squeezed everything out from “technology”
Technology has provided us with all means to expand our vision and imagination to heights unexplored earlier. But how far have we gone in reaching those heights? The answer to it lies in asking the correct question — are we really here to explore the potential of technology or are we simply looking for solutions to our problems?
To set the context right, I am talking about the numerous products/features that are developed on each sprint of a tech based organization. Before taking an example to explain further, let’s list down the ideal bare minimums for a feature/product release in a typical tech based organization:
- Needs: are the problems that need to be solved
- Detailing: of the needs which are usually documented in the form of BRDs (Business Requirement Documents) and then translated to PRDs (Product Requirement Documents)
- Prioritization: based on the criticality and the impact it will create
- Scoping: of tasks based on development efforts (time that it takes to develop) and sprint size (time that is available)
Another crucial aspect where the real story happens is in aligning stakeholders. Who are these stakeholders and why does a PM need to align them? In fact why aren’t they aligned already if the product is solving a problem? Most importantly, why so much entertaining the stakeholders, why can’t we simply go ahead? We will discuss this in further details later. However, for now, like any other thing on earth, a software product too has stakeholders and like it or not, the product is not getting built if these guys aren’t on the same page. Hence, in order to understand how a product is built, it’s important to understand who these people are and what they want
- Business team: these are the folks who are handling day to day operations, managing the P&L or simply put facing the customers in a B2C environment
- Tech team: these are ones who are actually writing codes, thinking about the software architecture or simply put, setting up the bricks in their place
- Design team: these are the ones who decide how the page should look like. Okay! for a lay man, design may not seem to be frugal. But, what if I tell you that certain key metrics as important as adoption rate are dependent on design elements. Every aspiring org has a set of talented designers who are responsible for creating the best experience for the user
- Analytics team: these are the silent horses who possess the capability of providing ground breaking insights. A good analytics team can generate ideas that are not humanly possible to achieve. This team also helps in validating hypotheses/problem statements that act as a foundation for any further development
- Product team: finally, the much revered ones (literally and sarcastically, at times). These are the ones who, in short, are the sole responsible owners for the delivery of the result
Here, although we get that a product manager is ultimately responsible for the final delivery of a product, but why is that considered to be a task? Well, the answer is simple. The stakeholders have their own set of priorities based on the nature of their job and a PM has to align these stakeholders. Let’s take a small example to understand the theory so far
Let’s say, there is a task at hand that needs solving as mentioned below:
Task: Provide calling feature for our customer facing employees (let’s call — partner) to speak to customers so that all calls are made officially and tracking of those calls can be done
Now, let’s assume the problem is validated and given a green light for development based on the impact that it’s going to create. Now, the options/approaches to get this done are multiple:
- Provide calling option in the partner app, or
- Migrate to external calling app through partner app (CTA)
Each of the approaches has its own set of pros & cons. While a user would would want to keep the feature as simple as possible and hence would be more inclined towards the first approach as it requires less switching between platforms, the engineering team would be keen on identifying the underlying challenges in each of the approaches. This brings us to the next step where the engineering team provides estimates (also called effort) for each of the approaches. For the sake of understanding, let’s say the tech team has given a 20 man-week effort for 1st approach and 2 man-week effort for 2nd approach.
While it is clear that 2nd approach is not the ideal solution but solves the problem with minimum effort as compared to the 1st approach, the final decision warrants a strategic call that weighs in:
- effort required to develop
- short term & long term benefits in different types of solution
- current position of the organization — a startup may not afford such timeline whereas an established org would always go for the ideal solution
In a nutshell, the first approach would have been more futuristic where the partner would be just one click away from reaching out to the end user. However, due to technical constraints, we don’t necessarily end up there all the time. And that’s how products are built.
Disclaimer: The argument stated above doesn’t associate with any particular company or industry. Nor does it claim to be all too pervasive. There are various cases where the context described above may be different