A holistic approach for a product manager’s feature analysis

9 min readJan 16, 2022

Every product team has different dynamics. Even though there are countless frameworks for how communication should be between teams in product management, you should embrace the differences. Some people spend a lifetime on how to connect in an ideal way. The world is full of amazing product companies that found groundbreaking solutions for intra-team and inter-team communication problems. They may or may not fit your company culture, the expertise of you and your teammates, or the size of your company; but there’s something you can borrow from each of them.

And we did so while developing our SaaS in-app story product, Storyly. We, as the product team, should be the communication senseis helping everyone in the company understand what our customers require. Before you communicate with anyone that can help you with the solution, you need to inhale and absorb the problem. There is no way you can get on board with the whole team for designing a new solution without understanding what is wrong with the current ones.

So we learned from failures, miscommunication, and a lot of waste of time before I come up with a solution, at least for now. Before we move on, you probably wonder what went wrong. There were 2 main struggles:

There were many missing points in the analyses. When you have something not determined at the beginning, you almost always need to come up with a mediocre solution. Because you are caught unready. Not just you are settling with a bad solution, but this is also stressful for everyone involved. This is terrible for quick shippers like every startup. Spoiler: We now have a checklist for this.
PMs need to share the problem and possible solution(s) with different audiences. In our case; we had different meetings, ad-hoc calls, tons of Slack conversations with designers, developers, and our product marketing manager. This was only the part before implementation. After, we onboard the customer success team and even some customers with what is upcoming. The whole process was hard to manage, especially if you have a lot on your plate.

We started to look for what could be out there for us. There are hundreds of studies about this: the chaos of communication, and problem-solving for PMs. Among many, I could say these are the top three that inspired me:

Basecamp’s Shape Up

If you are in product management for a while, you probably heard about Shape Up of Basecamp. Shape Up is a great framework for growing startups, mostly if you are having difficulties in shipping valuable features and improvements for your customers.

Key takeaways of Shape Up, IMHO:

Care about the features/projects at a higher level, see the value from a business impact perspective. Leave the tasks to designers and developers. Autonomy is great if you are working in a great team, which we do.
Consider the appetite: How many days/weeks are you willing to spend for that feature? Even if you cannot be certain, it is a good practice for the whole team and helps you regulate the priority and the effort investment.
Decide the no-go’s: What will be excluded for implementation and design? Know where to stop. Leave out or phase the most complex or uncertain issues.
Emphasize the rabbit holes: While analyzing, you might encounter a few crucial points. Try to figure out what they are. Then repeat them, explain them.
Pitch the problem, the appetite, and the solution. Discuss them with the team. Sketch while working.

Shape Up is super helpful to us, however, we needed adjustments. Because as I said earlier, every team has different dynamics. For example, we did not want to be (and honestly, could not be) highly specific about the appetite and the six-week cycles. We are not close to doing this.

Also, do not evaluate Shape Up with just what I said above; it is much deeper and detailed of course, and can be just the perfect fit for you. I strongly recommend you learn more about the framework.

Miro’s Product Alignment Document

Farbod Sarah’s introduction to product management in Miro is quite inspiring. They have hundreds of employees (in January 2021, Sarah says the number is 600), and all the product teams are internally aligned and constantly sharing feedback. Sarah clarified their approach so well that, even just this article is so constructive specifically if you are working at a fast-growing company.

What I learned from Miro’s PAD:

Frame the problem by including user stories, understanding the underlying problem and the reasons why you should solve it, doing sufficient competitive research, stating the audience.
Frame the proposed solution, think about alternatives, and explain why they are rejected. Take into consideration if you need data migrations, explore the risks.
Work on the launch plan, plan the onboarding, and the whole GTM strategy.

In Miro, they use this document to communicate between product teams; we adjusted some steps from their approach for pitching the problem and the designed solution to different teams such as the development team as well as inside our product team.

Intercom’s Team Alignment Framework

If you are doing product work, you are most probably amazed by Intercom’s Product Blog a lot. Their team alignment framework is particularly simple and easy to implement in a PM’s daily work.

The framework is about how you should approach a problem and make sure everyone on the team is aligned on the problem statement. Since every problem requires different things to be solved, it’s a great and super useful idea to put things into a simple matrix:

Innovation: At which level do we need innovation to solve this problem? Will it be a neutralizer or a differentiator?
Investment: Shall we spend a lot of time building this solution?
Urgency: How quickly do we need to solve this problem?

Although this framework is handy to keep all stakeholders posted, we use this in our analyses mostly to get aligned with the development team.

By feeding ourselves with the acclaimed frameworks, we came up with a Feature Analysis Approach that is tractable for us. It has 2 main parts:

Build up for problem framing
Requirements for solution framing — including technical, design, product marketing needs.

Build Up

We frame the problem here.

Problem. We should be crystal clear about the problem that we’re trying to solve. We address the missing pieces in our product precisely, and how those missing pieces hamper the users in reaching their goals and expectations.

It’s always good to give some examples of failed attempts with the existing solution. And we link these problem statements to the opportunity that we want to catch.

Why. This part is for explaining why this problem matters to us, and how we know this is the right problem to solve. There might be many things to attack, but we prefer to handle this issue. We should clarify the importance.

If there are other alternatives for solving this, we include them here as well and discuss why they will not work and why they are rejected.

The most two critical parts to mention in this section are the assumptions with customer jobs and market research regarding the problem or the planned feature.

In a nutshell, at this point, we need to make sure everyone is aligned with why we need to solve this problem.

Audience. We put links to customer interview notes and recordings or customer-related data observations here to identify for whom we are solving this problem. Also if we have pilot customers, existing customers looking for this solution, we talk about them here. Sometimes a feature is an enabler for a lead, we include them under Audience too.

Competitive Research. Our products have direct, indirect, and potential competitors. We try to interpret if the upcoming feature will be a competitive neutralizer, differentiator, or delighter.

If it’s a neutralizer, we examine their approach to the problem.

Strategy Alignment. We set our product strategy quarterly or bi-quarterly. Every new feature we choose to build fits our product strategy in some way. We also place the aforementioned Intercom’s Team Alignment Framework here in a simple matrix for aligning the development and product teams.

Success Metrics. For the post-release of the feature, we decide on some (usually high-level) metrics to track. There could be many types of data here including the number of paid users actively using this feature, the decreased number of requests/complaints related to this, or the number of paid customers gained.

Requirements

We frame the solution here under several headings.

Solution Analysis. We often divide our proposed solution into pieces to release one bit at a time if we can. Not every feature can be broken down as such, and in those cases, we take the scope as a whole. So the first thing is always the scope regardless of the shippable pieces.

The appetite comes into play in Solution Analysis, we try to discuss how much effort we are willing to put in this work and how complex it is to realize the solution from our perspectives.

The biggest portion of the Solution Analysis is extracting the sub-features and requirements on the mobile and web SDKs, the backend core, the dashboard, and the creative studio for content creation for our product Storyly. Requirements are functional (usually more technical) and design-related. To be on the same page with designers, we mostly include wireframes to visualize the feature. After the design team is ready with the UI/UX design, we put the design document here.

Storyly has multiple components and many user roles and permissions within the product. It has mobile and web SDKs with several versions supporting many platforms, therefore it is crucial not to break the experience for any of the users or their users on the mobile screens. To tackle the potential issues, we created a checklist that we include under Solution Analysis:

The Checklist
A bit simplified to make it commonly comprehensible.

Does this feature affect the earlier SDK versions end-users? How?
Does this feature affect the content Studio or the templates? How? Do we need to warn and inform the users visually?
Does this feature affect the interactive stickers used on our content?
Does this feature affect the existing users of the feature? Do we need migration? Do we need to contact the existing customers?
Is this feature accessible to all roles and permissions? Do we need extra permissions for this?
Do we need to update the Analytics or the Overview page (the home page for overall metrics)? Are there new metrics and events that we should present to users?
Do we need to track the users' behaviors regarding this feature?
Will this be a valid feature/improvement for web stories?
Does this feature affect app/instance/story group/story level?
Should we update the Terms of Use?
Should we update the Privacy Policy?
Should we update the landing page(s)?

Launch Plan. Storyly has various pricing plans that are highly based on the active users of our customers, and also their feature needs. Thus, we argue in which plan we should place this feature. Also, sometimes we launch closed betas with pilot customers; this is the section where we give customer names and estimated dates.

GTM Plan. We discuss the positioning and the messaging of the feature with our product marketing manager in this section.

Every feature has a tier (from 1 to 4); and we announce them, educate the users, position, and do the messaging accordingly. Tier 1 features are the ones that will projectively affect the revenue the most, thus require more advanced marketing activities.

Rabbit Holes. Rabbit Holes is one of the most useful and simple parts of Basecamp’s Shape Up. We shout out the details and requirements that are particularly vital.

No-go’s. Generally, due to complexity or ambiguity about the use cases, we exclude things from our feature analyses. We discuss these here because we do not want to spend time on things that are hard to validate or vague. These are the things that are out of scope.

Onboarding & Feature Adoption. As the title is self-explanatory, we clarify how we should onboard the users. Emphasizing onboarding in analysis helps us not skip this while testing the feature after implementation. While planning the onboarding, we consider the experience for:

The existing users: the ones who will frequently use it, and the ones who will rarely use it.
The newcomers

Planned Phases. Usually, our features have the next steps that are not covered here because it is difficult and time-consuming to build or because we want to observe the first stage’s results first. If we plan to add new capabilities to the feature, we discuss them here.

When we need to prioritize the sub-divisions of the feature that is analyzed, we do it in this section too.

Appendix. We put all supplementary documents here.

Addendum. Occasionally we discover new information after publishing the analysis and add them here.

This approach helps us ship features without friction in communication for some time now. It might lack things, or need to be simplified in the future depending on our products and team structure. As always, any feedback is welcome. Reach me on Twitter @cansutet ✨