Product Management Framework

The author employs an experiential narrative to provide a contextual understanding to the reader by introducing them to the setting, needs, inspirations and applications that went into the development and implementation of the framework. It starts with highlighting the structure of a product studio and how it differs as a business model, followed by the needs that were observed by the team that is building this framework across the projects they have worked on previously. To solve for these needs the following sections focus on the frameworks, models and tools already in place and what elements in them were used in curating this framework and getting into the high-level description of the model with a simple example to relate with.

“We are a product studio”

It was also mentioned on the website and on the page that described the role I was while applying for, this was the third time it was mentioned by Saksham Mendiratta during my interview ******. I didn’t dwell on it much back then, compartmentalizing it in some part of my brain though it was an important influencer of my decision to join until one day I was asked by an interviewee, “Why do you call yourselves a product studio?”, By this time, I was already involved in a project and my observations thus far contributed directly to my answer “Because we work as an extended team of the customer’s product team”, quite simplistic in retrospection. The compartmentalized thought took a more assertive command soon after, spiking my curiosity to understand the studio model more expansively. Turning to my peers, the internet and my own observations here’s what I have on a studio model.

At a glance the studio model, specially a product studio would be mistaken for a design agency, a product consultation firm, a company that develops the tech side of a product or an outsourced product design entity. It is in a way all of the above, however with clear demarcations in the way it is structured as an entity and the kind of value it brings to its customers. As an entity, we generate revenue by working with customers on the implementation of their product ideas and solving specific problems they bring to us, we act as a product partner and design partner. At the same time, ideating and building products internally as potential spin-off businesses while inheriting the best of both the agency and consulting models.

• Scale and Collaboration : As a product studio, the kind of projects we take on differ in their requirements, i.e. scale that is directly proportional to the degree of collaboration we need to establish and build on to deliver the desired value. How is ‘Scale’ determined?

1. Stage at which the Product is when we are brought in, as the scope of experimentation and research vastly varies from ‘development’ to ‘saturation’, thus also changing the kind of involvement we go through.
2. Stage of the business, adds more context to the products stage and to better associate our requirement by understanding the bigger picture of the problem statement(s) in context.
3. How the problem statement is defined and presented to us, this aspect varies in the kind of efforts need to be taken by us, for open ended problem statements the approach is wider while very well articulated problem statements require a more deep dive approach.

• Team structure : The average size of the core team working on any project here is not more than 5, though we do use specialist freelancers as an when the requirement arises managing them internally as an extended part of our team. However, the ones directly associating with the customer’s team are limited. When seen from the client’s perspective, it is uncluttered and adds flexibility and malleability to the functioning and operations making both the teams, internal and customer’s tightly-knit.
• Communication : Extending advantages of the team structure seep into the way we communicate with the customer. A distinctive plus point for the customer is that they directly interact with the creatives, making it efficient and unlayered thus evading the viscous exchange of information through many until it reaches where needed.
• The studio model enables teams to ask the tough and necessary questions when presented with a problem statement, of its impact and purpose and understanding the problem more thoroughly and not jumping to draft solutions on the whim. Making it crucial for establishing an association with the customer’s team by making genuine efforts to be conscious of the whys’ and how’s of a problem.
• Automated Ownership : Your problem statements are our own, we work on the product like its ours is an unsaid thought process brought about by the kind of involvement extended to the team and the thought needed to navigate through the project over time makes us adopt high sense of accountability while pushing the quality standards above and beyond what one might find, it is also the pride and the regard each team member holds in their work. This is further amplified by working directly with the decision makers from the customer’s end.
• T-Shapedness : In the kind of people in the studio and also their backgrounds, a product is many things and needs more than just one kind of skill or perspective to deliver value, which is why the individuals in the studio have diverse experiences and professional backgrounds with a deeper inclination and expertise in a niche skill, namely product design, product management or business design, creating a pallet of talent that when combined are thought machines able to benefit and influence a product at any level.

As effective and apt the studio model in a product perspective. It is not entirely immune to certain lapses and anomalies that need clear establishment of managerial processes and utilizations of certain frameworks to navigate and deliver quality of the highest standard. I would not be dwelling on these processes and frameworks just yet, but focus on the observed lapses and recurring bottlenecks to bring more relevance to the points where needs were identified. To best expose the anatomy of these needs, I would be using the functionals task we as a product team broadly perform.

Irrespective of the type, scope and stage of projects there are some task which could be classified as constants;

1. Setting and quantifying expectations both for the customer we are working with on a high level and on a task basis as well as the individual or team working on it, at this stage which was before we began working on a problem statement we observed a need to rightly account and record the right perspective of the problem / task in-hand, not a recurring one but a happened quite often to miss.
2. Clarity of teams or individuals needed to be involved for a project or a specific problem statement at a given point. As an extended product team, we needed to interact and exchange knowledge with multiple teams and departments across the customers organization. Unlike the traditional agency approach with one point of contact for both parties, we thrive on open and direct communication with whoever necessary. However, we failed to preempt this at the earlier stages to help account for the parallel timelines running on the customers end along with ours and how they would impact our timelines, while accounting for the time needed to relay the exact requirements to customer teams mid tasks that directly affect the hand-off dates overall.
3. Documentation of efforts and project progress is a crucial call back, reference, communicational tool while working across cross functional teams spanning multiple tiers. We observed a need to make it more than that and use it as a template, almost like a canvas which would evolve as the project progressed but also imbibe the previous progress made by the customer’s teams before us that was missing previously in a formatted manner.
4. Onboarding of new resource mid project from the customer’s side, an internal resource or freelance associate involved multiple knowledge transfers and some time for comfortably understanding the big picture and multiple perspectives before they even began. Could we make this onboarding more efficient without affecting the pace of work and the end delivery timelines?, was needed here.
5. Feedback Mechanisms are very crucial for us, and owing to our process of work being highly iterative we needed to induct and try better ways of receiving, recording, working on and delivering seamlessly at the right time. Due to multiple stakeholders’ perspectives mattered, a single call to facilitate the same was less productive due to the time and convenience of all people needed to be accounted for, let alone the scheduling and recording them timely to further our progress on them. Summing up to solving for three main points or questions, needing feedback when it matters the most, how else could we take it and the scope of it tapping into Time : Process : Quality of feedback.

None of the above are stand alone problems and must not be viewed as one, but must also include the open ended and explorative nature of the problems we solve for, and the multiple interactions of stakeholders at any given point, all happening remotely and highly iterative in nature.

The Framework is nothing new in its essence, but an ingenious attempt to assemble parts and modules from existing product management frameworks and models to fit the model we operate in and solve for the problems highlighted in the previous section. The Framework draws its inheritance from the following execution processes, tools and frameworks most of them coming not just from a UX and Product Management perspective but also from Manufacturing and Medicine:

• Value Stream Mapping :

This framework draws roots from lean manufacturing that helps analyze, design and manage the flow of materials and information required to bring a product to customer. Tweaking this to suit our purpose where there are multiple handoffs, while mitigating the fact that value stream mapping was build around tangible products. More than the focus on activities, we needed a process to identify and map the flow of value to the customer. Aiming to solve for understanding the problem statement, the underlying value that we would be delivering and would that be in-line with the idea of value the customer has. The identification of value would help drastically reduce wasteful processes, features and activities that could be prioritized later also allowing us to pre-empt the kind of teams and resources we would need to be a part of the process early on.

• PDSA Cycles :

A documenting tool used extensively in medicine and healthcare to test change. Plan, Do, Study, Adjust is inline with the decentralized planning principle. The optimum use was identified at the stage after the value stream mapping was done, to plan and document the action or sprints we would be needing and the timeline we are looking at for the array of problem statements to be solved. The cyclic and iterative use of the tools also made it apt for the nature of work we do, adding depth and order to our much needed feedback mechanisms. Thus, solving for documenting efforts and project progress.

• PHEART :

Google’s UX framework ‘HEART’ is a simple series of user-centered metrics allowing to measure the user experience on a broad scale helpful for decision making in the product development process. Though the metrics here; Happiness, Engagement, Adoption, Retention, Task Success do make sense in a product perspective but the counter-metrics they are evaluated against are more valuable to us. As the problem statements defined for us are broad in their spectrum, we would be needing a broader and more flexible metric bracket to refer them with. Hence, the GSM within the ‘HEART’ framework is what we ended up using. Here is how we up them in perspective to suit our requirement:

• Goals : High level and derived from Customer Value
• Signals : Hygiene indicators of positive and negative trajectory of the process and tasks employed to deliver the said goals.
• Metrics : Set by individual team member on their sub-tasks which are official parameters used for measurement.
• GIST :

Product roadmaps are great for a long-term, stretched and not completely compatible with the nature of product problems we deal with on a recurring basis. We needed something that would help plan for shorter iterations and planning better delivery timelines for problem statements. That is where the GIST framework, throws light on how we could solve for planning the sprints. Goals, Ideas, Steps and Tasks under the ‘GIST’ framework helps put goals and problem statements in perspective. We are able to break them further down into actionable chunks given the nature of exploration they needed we could take up and execute in smaller but more relevant and meaningful sprints. Thus solving for sprint planning and day to day work planning, bring in the clarity and direction in work.

As I explained in the previous section the inheritance and where the metrics would be coming from, I would be expanding on the way it is implemented here. This implementation has everything to do with the way we navigate value through the entire journey of solving problems for our customers and why it makes sense and is working for us. Though it did not start with this, we evolved it over two projects spanning almost four months on a retainer basis. However, before we dive into the parts and implementation of this framework a contextual understanding is needed to relate with the effectiveness and see it through our lens.

Let’s assume a product that has passed the product-market fit stage recently and needs to sustain the growth by driving more subscriptions and in-app purchases. They aim to make the in-app experience better by redesigning and redoing certain modules of the product.

Implementation Timeline and Metrics :

Here are the 5 metrics that this framework backs on in a cyclic nature.

Goals: High level and derived from Customer Value

The goals as defined here by the customer are to increase subscriptions and in-app purchases, but we need to know more, therefore breaking down the goals into smaller problem statements that can later integrate to solving the larger problem. Timeline wise, this happens even before we start working on the product. We take almost 2 to 4 weeks to understand and get the entire system in place to figure how each variable would play towards the end goal. In these initial weeks, we dive deeper and speak to the teams on the customer’s end, do our own secondary research and start building a timeline and develop an understanding of the kinds of resources and teams we would need to possibly engage in the future.

Signals: Hygiene indicators of positive and negative trajectory of the process and tasks employed to deliver the said goals.

Once we have a fair understanding of the goals, in at a high and actionable level, we employ the necessary signals to define the quality of value we would be needing and further defining the tasks and sub-tasks needed to deliver that value. Think of this as sprint planning or the Steps and Tasks planning from ‘GIST’. Here we break down the problem statement and spread it over a calendar to provide a better timeline clarity for us internally and for the customers. All this happening both before we kick-off Sprint 1 and also during ongoing sprints.

Metrics: Set by individual team member on their sub-tasks which are official parameters used for measurement.

Each sub-task, task or problem statement has certain crucial areas which define the type and number of metrics that make sense. As per our case, increase in the number of subscriptions is the high-level metric. But when broken down further, we could define the number of clicks on the purchase button in the app as a metric whose increase or decrease would be directly proportional to determine our success or failure. Similarly, at times not all metrics would be quantifiable in nature and would be more design and experimental in nature which is where defining a grey metric would help seek right feedback at the right time while keeping the momentum in check for achieving the said high-level goal.

Progress/Past: The past efforts made to solve the problem statements.

As the process of our task would be explorative in coming up with solutions for the problem statement after systematically understanding the underlying problem, recording progress helps us in two ways, First, being at par with the solutions and iterations that were tried by the customer before and the way they performed which would save us time and effort to work on freshers solutions. Second, record all the explorations we have build and proposed to solve a problem. Almost like a graveyard of the stuff that didn’t work this time for this specific problem.

Teams: The stakeholders from each side would be communicating and exchanging intel and progress.

Streamlining our efforts for establishing better feedback mechanisms, easing the onboarding of a new resource to the project and communicating optimally across, teams is an essential part of the framework. This eliminates the confusion on the work and role each member as a part of the larger team plays and who makes the decision for a specific task or function.

All this happening in a cyclic process, making us flexible yet structured in the way we manage and go about solving complex problems for our customers.

It is still an evolving framework as it has only been implemented over two projects with distinctive scopes and would need bigger sample sizes and scopes of projects to implement and subsequently test across unexplored behaviors of problems and types of organizational customers to help further validate its effectiveness.

The current implementation team is small and specialized, which opens at how does it accommodate larger teams or more interdependent needs over time or would be only suitable for relatively smaller and specific product and design teams.

Highlighting the aspects of the growth and expansion of the framework for internal teams more fine-tuning and templatizing is needed for accommodating the Signals and Metrics in an internal sprint perspective.