How PMs Can Use Bloom’s Taxonomy to Learn About a New Product

Starting a new job? Here’s how Bloom’s Taxonomy can help product managers understand the ins and outs of their new product quickly.

This article is geared towards product managers who have found themselves inheriting a new product, whether that be from changing companies, taking over a new product line within your company, or something else entirely. It is written for more technical SaaS products (such as Stream’s API solutions), but is generally applicable. This article might also be useful for developers or anyone who needs to have a baseline understanding of a fairly technical product as a part of their role.

As you begin to learn about your new product, it’s key to be comfortable with not knowing everything for a while. Recognizing that it will probably take a fair amount of time to learn all the ins and outs of your product —particularly a highly technical one — will put you in the proper mindset to begin creating a deeper understanding of your product. That said, there will be times when you have to act before having as deep of an understanding of your product as you would like. Remember that, as a product manager, you likely have made decisions in ambiguity before.

To improve your confidence while you are still getting your bearings, it never hurts to have a trusted peer or manager — ideally someone with a bit more product knowledge than yourself — to review your decisions first. I like to call this a “smell test,” which is simply asking someone “Does this smell right to you?”

Bloom’s Taxonomy: A Framework for Understanding

Bloom’s (revised) taxonomy provides a framework to evaluate your own understanding of your product. This framework will likely be familiar to anyone who has taken cognitive psychology courses or completed educator training.

Bloom’s taxonomy has six stages: Remember, Understand, Apply, Analyze, Evaluate, and Create. A fair amount of product management is in the “Evaluate” and “Create” stages. In fact, our role relies on it, as shown by the common mantra of having “Strong Opinions, Weakly Held,” which falls neatly in the “Evaluate” stage. Since each stage builds upon the former, we cannot start to Evaluate and Create without first being able to Remember, Understand, Apply, and Analyze.

So, how do we get there?

Remember: Define What to Know

The trickiest part of the Remembering stage is first defining the universe of things that you need to know. Fortunately, your company likely provided you an onboarding guide or at the very least has product documentation. At this stage, you should try to read everything you can find about your product. Potentially fruitful sources to read through include:

  • internal documentation related to your product
  • public product documentation
  • support articles
  • your company’s internal knowledgebase
  • blog posts, third-party articles, or guides about your product
  • user onboarding guides sent to your customers
  • depending on the nature of the product, the source code itself

Take note of helpful sources as you’ll be returning to them. For now, I’d recommend spending no more than a few days doing this.

Your objectives right now are to simply to be able to:

  • Recognize concepts that are related to your product, and
  • Recall and define terms or jargon that are associated with your product

Understand: Make Friends

Once you feel you have a basic grasp of the concepts and terminology for your product, it is time to start making friends. There are almost certainly many other individuals who have a strong understanding of your product, but from a different perspective. These individuals are an absolute treasure trove of knowledge that you should tap into. Broadly speaking, these perspectives are from: the business, the customer, and the builders.

The Business

You likely already have a decent sense of how the business thinks about your product from reading through your website and blog posts. To further this, you can reach out to your sales and marketing teams to ask them for what collateral they might use for customers, and even ask to do some ride-alongs for sales calls! Your sellers and marketers are very good at explaining the value your product provides and how it works, and you should take advantage of that.

The Customer (secondhand)

A great low-risk way to understand the customer’s perspective, before you have the product confidence to chat directly with your customers, is to make friends with your customer success department. If you’re shy, you can start by looking through some open support tickets, though this can also quickly become overwhelming. Your customer success team will likely happily give you an onboarding session, or at the minimum allow you to sit in as they onboard customers. Making friends with your CS department early on is incredibly valuable. Any question you might have about your product, they probably have heard many times before. If you don’t talk to anyone else, talk to your CS team.

The Builders

The final group you should make friends with are the builders. By this, I mean anyone who has helped build your product, including your developers, your team lead(s), and your infrastructure team. These will likely be much more technical conversations than those with the other two groups, but they will be the only ones able to answer questions about why certain features are the way that they are.

In general, a willingness to be a bit vulnerable and ask “stupid” questions can go a long way. In reality, there is no such thing as a “stupid” question, only impatient people; being unabashed with your questions has the added benefit of quickly identifying who on your team is patient and constructive. Eventually, once you’ve asked enough questions to be able to start explaining the product in your own words, try to start “Applying” your knowledge.

Apply: Get Your Hands Dirty

The next step is pretty simple: use your product. If your product is an API, build a sample application. If it is a SaaS offering, ask if your sales or CS team can set you up with your own account. If you are not sure what to build, look at the use cases on your site, ask your CS department, or try to make a clone of one of your existing customers. As you pretend to be a customer, take note of anything that is still confusing to you. This is both great product feedback for your product’s documentation, and a good indicator of concepts that you might want to go back and revisit documentation or have more conversations about.

Your goal for this stage is to be able to successfully implement — whatever that looks like for your product — every major feature or concept in your product. If you are feeling unsure, spend some time sketching how your product might be applied to a variety of known personas, use cases, jobs-to-be-done, or other customer framework you are familiar with. This entire step will probably take you a fair amount of time, and it is easy to cut corners. It might be helpful to ask to demo it to your manager or someone else with deep product knowledge so they can give you feedback and point out any gaps or best practices you might have missed.

Analyze: Find the Edges

Once you feel like you could reasonably help a new customer from a standard use case onboard onto your product, it is time to compare your product to the market. A simple way to do this is through competitive analysis. In short, you’re looking to understand how your product stacks up against the competition. You should be able to identify where you’re stronger, and where you’re weaker. One way to go about specifically finding what to produce is to talk to your sales team and see what collateral might be helpful for them to have on hand, and go and make some of it.

You can also ask your friends in sales to do more ride-alongs, and ask to take a more active role after the fact discussing how your product satisfies their needs (or not).

By the end of this exercise, you should have a good sense of your product’s strengths and limitations, including it’s sharp edges.

Evaluate: Form an Opinion

Congratulations! We are now at the level of understanding needed to facilitate most product work. Now is a good time to start thinking about product strategy and having opinions about your product. It is also a good time to return to the product feedback you made for yourself when you were applying your knowledge and see what is still relevant. If you have inherited a product roadmap along with your product, you should now engage with it deeply and start to form opinions about it, including things you might like to add or remove. At the minimum, you should be able to make a case for every single item on your roadmap. You should be at a level of understanding where you’re able to gather data to support your roadmap choices (also known as validating your hypotheses), and identify success metrics (KPIs). When you’re ready, you should start to have conversations with your manager, your engineering lead, and other stakeholders to socialize your product’s roadmap.

By the end of this stage, you should have a good understanding of your company’s vision, the role your product plays in that vision, and have strong opinions about your product’s roadmap.

Create: Design your First Feature

The final step in your understanding is to create. As a PM, this probably means putting together a research proposal, conducting user research, and collaborating with your design and engineering partners. Ideally, this research can inform your product roadmap and help refine the scope or design of some of the features on your roadmap. Once you have a design document, you are ready to implement the whole product socialization process. This varies fairly significantly by company so you’ll want to lean on your manager for guidance here. This socialization very likely includes some of the friends you made earlier on, which can make it a bit lower stress.

Always Be Learning

Ultimately, as a product manager (or anyone working in the SaaS space), your knowledge of your product will be constantly evolving. Even if your product does not change, the world around it will, which may affect how users utilize or engage with your product. To keep up with these changes, I highly recommend staying in touch with the friends you made earlier in this post.

Beyond providing invaluable feedback, they often will be the first to sense that the world has changed around your product, which can only help you be more successful in your role. While this post may have kickstarted your journey learning about your product, it should not end here.

Interested in learning more about Stream's API solutions? Activate your free Chat trial today!