Launching Analytics (and other) Tools in a B2B SaaS, Parts 2 & 3

Leave a comment

Parts 2 and 3 are Implementation and Rollout. Check out Part 1, Internal Buy-In & Analysis

Part 2: Implementation

Determine what work needs to be done

What does implementation look like? Read (or at least skim) the implementation guide. Determine what you need to do before anyone implements the work.

A common item to figure out for both analytics and feature flag software: what metadata do you need? For example, will you want to analyze (or turn on feature flags) based on user permission? Based on state, or subscription type? Etc. 

Figure out who will do the work and align on requirements

Read more: Launching Analytics (and other) Tools in a B2B SaaS, Parts 2 & 3

This may be another ‘work with your manager’ thing, or it may involve working directly with the head of engineering and head of tech support, for example. 

Once that’s done, work with whomever was chosen and ensure they understand what you’re looking for. This may be done via a ticket and/or a discussion. Include links to any implementation documentation you were able to find. (Pendo example, MixPanel example)

You will likely want to do a POC (Proof of Concept) in a dev environment first, and be involved in testing the initial implementation. 

Part 3: Rollout

Align on who will help and discuss governance

Depending on the size of your company, you’ll likely need help with this part. Understand who wants to be involved from each team, and who wants to have additional involvement. 

For example, at my current company, I have a “Pendo steering committee” who brainstormed page and feature tagging guidelines with me, and have assisted the launch in other ways. We’ve discussed which team “owns” the guides, and what other team they’ll work closely with. 

Get and give training & documentation

You’ll note that I put governance before training. I think it’s helpful to know who your key players are internally, and what the guidelines are even before training. However, if this is your first time, you may need to do training before you can create guidelines.

Training may be more formal: Pendo insists on formal live training being included, for example, and also has Pendo Academy (LaunchDarkly also offers an academy). 

From https://www.pendo.io/academy/ 

Or it may be made up of stitching together various tutorials and guides (Posthog example).

Document the training and guidelines somewhere that people internally can access it (i.e. Confluence, etc.). Make sure the most commonly requested help is well-documented to save yourself time in the long run.

For example, I created a ‘replay’ training page with a short video to explain how it works for an analytics tool; this could be sent to support team members who only needed to know how to use this feature. 

Last but not least: keep it going

Ensure there’s a method for ongoing questions and issues. You could create a Slack/Teams channel for folks to reach out in. 

If you choose to take this kind of project on, know that it will be a lot of work. But the results, if you succeed, are worth it. 

Best of luck!

Screenshot of analytics from Pendo

Launching Analytics (and other) Tools in a B2B SaaS, Part 1

Leave a comment

I have initiated and led the launch of Pendo twice in the last year or so, at two different mid-size B2B SaaS companies. At my previous company, I also led the standardization of MixPanel labels, and helped roll out Posthog and LaunchDarkly. The last of those is a feature flag tool, not an analytics tool, but the steps are very similar. 

If you’re interested in bringing a tool like this to your company, then this article is for you.

I’ve broken it down into three parts:

  • Part 1: Internal Buy-In & Analysis
  • Part 2: Implementation
  • Part 3: Rollout

This article contains part 1; parts 2 & 3 will be released in a follow-up article. 

Part 1: Internal Buy-In & Analysis

Start with your manager, and see if there’s any interest in the tool you’d like to bring on

If your manager says spending is frozen for the year, all of the analysis and data in the world (likely) won’t help. 

Assuming there’s at least the possibility that this could happen…

Read more: Launching Analytics (and other) Tools in a B2B SaaS, Part 1

Discuss the idea with potential stakeholders and understand their needs

For example:

  • Customer support & QA: Replays can be very helpful in troubleshooting
  • Data & Analytics: For an analytics tool, they should be brought in early. At one company, we were able to ingest the data from the 3rd party tool into our data warehouse
  • Security / Head of IT: Understand what the requirements are for your company (ex: is SSO required?)
  • Engineering: They’ll be implementing your tool, so talk with them and see if they have must-haves or areas of concern
  • Product management & design: These tools can be great for customer insights, both in terms of quantitative insights (data) and qualitative (replays)

Understanding the needs of each group leads us to our next step…

Analyze the options out there, and determine which tool fits your company best

Create a matrix similar to this:

Product AProduct B
Feature 1 (nice-to-have)❓✅
Feature 2 (must-have)✅❌

This can help you quickly narrow down your options. 

Tip: Perplexity is a great tool for quickly finding out what features each software has; however, like all AIs, it can hallucinate or misunderstand, so double check what it’s telling you by clicking on the links it provides.

Including pricing as a ‘feature’. However, most times you won’t be able to find the pricing on the site, so you’ll need to…

Talk to your top vendor choices

There’s usually a form on vendor sites that you can fill out if you’re interested; they’ll usually email you with a Calendly-type link so you can set up an intro meeting. You can also ask for a demo, if you’d like to start there before going to pricing. (Mixpanel sales contact example, MixPanel demo contact example)

Bring any relevant stakeholders who want to be very involved or who have questions; for example, bring engineering if they have implementation concerns.

Come to the meeting prepared where possible. Some software charges based on MAU (monthly active user) of your end product, while others charge on the number of employees using the vendor’s software. There may be other variations as well. 

Ask any open questions you have, such as “we couldn’t find if software x does y, can you please clarify?”

Once you receive the estimate, fill in the ‘pricing’ line of your matrix.

Once you have all of this together, it’s time to…

Present options back to the boss(es) and decision makers

This will be very dependent on the business. At a large company, you may be working your way up through the ranks, or maybe there’s a formal process. Always loop in your manager.

At a smaller company, your manager may tell you to go ask the CTO/CEO directly.

Use everything you’ve learned so far. Since you got buy-in during the stakeholder step, explain how this tool will help x y and z teams, not just your team.

Focus on the items you know the boss wants to see; if they’re security minded, say upfront that PII isn’t being shared and the vendor is SOC 2 compliant, for example.

Present in the way that works best for your audience.

Bring visuals, if that’s what works:

From https://www.pendo.io/product/analytics/ 

Or case studies:

From https://mixpanel.com/customers/kkday-case-study/ 

Contracts

How contracts are handled is different per organization; figure out whether who is the final signer, if someone else needs to handle further negotiating cost, etc. 

With some vendors, you may do a POC (proof of concept) before the contract is signed.

Once the contract is signed, it’s time to get started!

Stay tuned for Parts 2 & 3: Implementation and Rollout

chaos top right, order and data bottom right, representing agency vs in-house

Lessons From My First In-House Product Role

Leave a comment

As I start a new job tomorrow at ChampTitles, I took some time to reflect on what I learned at Patriot Software over the last 5 years. 

I was struck by how different my experience was at an in-house company, versus my previous 11+ years at agencies.

While I was in a different role at agencies – UX, rather than product management – my time at Patriot Software showed me there are unique advantages to being in-house.

Continue reading →

Building with AI: Getting Started with Bolt.new and v0

Leave a comment

I was talking to a junior dev the other week. I kept asking them to remove this duplicate status in one part of the app, and the dev kept sending the app back to me with the same duplicate in place – frustrating! We talked about it, and the dev explained their plan to fix the issue, once and for all.

I asked: “why wrap this div in a conditional render, instead of getting rid of it? To clarify, there is a second div, with class flex items-center space-x-2, that also displays the status, that works just fine and I’d like to keep.” 

The dev explained “The reason for conditionally rendering the div with the class inline-flex items-center px-2 py-1 rounded-full text-xs font-medium (which I’ll refer to as the “status badge”) instead of removing it entirely is to maintain its utility when a task is completed.”

I said “Let’s just get rid of the ‘status’ idea” and finally, the problem was solved! 

At around the same time, I was working with a junior designer. When I suggested we try a change in design – from boring blue-on-white to green-on-black – there were a LOT of accessibility problems at first! And too many of the calls-to-action were primary. But after some additional feedback, they got their act together, and it’s looking pretty good now.

Continue reading →

Do’s, Don’ts, and Personal Pet Peeves of Product Manager Resumes

Leave a comment
Image from Craiyon.com, an AI image generator, of an abstract resume
Image from Craiyon.com, an AI image generator 

Looking back on my time as head of product management at Patriot Software, I reviewed more than 1,000 resumes while hiring over half a dozen product managers at Patriot Software.

Some resumes stood out with clear, compelling storytelling and measurable impact. Others had vague descriptions, fluff, or outright mistakes.

A great product manager resume isn’t just a list of responsibilities or numbers; it’s a story. Getting it right can mean the difference between landing an interview or getting overlooked.

After seeing the best and worst of PM applications, I’m sharing my do’s, don’ts, and personal pet peeves to help your resume stand out.

Continue reading →

Encouraging a Product Management Team to use AI

1 Comment

You’ve likely seen countless articles on why AI is transformative, and you’ve read about the various and sundry LLMs that are out there.

This article takes a different approach: how do you actually get your product management team to consistently use AI to help level up your team?

While I don’t claim to have cracked this nut entirely, it is something that I’ve worked on, and thought it would be helpful to share with other product people interested in bringing AI to their teams.

Continue reading →

Product Management Career Day: An Adventure in Teaching Kids

Leave a comment

Last Wednesday was ‘career day’ at my fifth grade daughter’s school. They’d asked any parents with “interesting” careers to volunteer; figuring that product management should count, I signed up.

I had thought that it would only be fifth graders that I’d be teaching; they told me that there would be 5 classes, and that I’d be in the same room the whole time. With about ~20 kids per class, for 2.5 hrs, it sounded difficult, but doable. That’s what I thought, anyway…

Surprise! Teach the WHOLE School!

whiteboard from the class where I didn't have a computer for my presentation.

When I got there, it turned out to be 6 classes, for all of the grades – that’s 3rd through 5th at my daughter’s school – with 40+ kids per class! Each class was in a different room, and the schedule they gave me was less than accurate in terms of which room I was supposed to be in. In the last room, there wasn’t even a computer, so I did the presentation with a whiteboard (that was probably my best class, actually!)

While it was an exhausting experience, it was also a rewarding one. I’m sharing more about that experience in case anyone else is doing a ‘product management career day,’ and wants to use any of what I put together for the kids.

Continue reading →

Metrics Sharing at a PM Community of Practice

Leave a comment

As part of our Product Management Community of Practice, we regularly share metrics. 

We experimented with a few ways this could work. 

At one point, it was anything goes:

  • Data to help make a decision
  • Pre-shaping opportunity estimate
  • Team dashboard
  • ROI estimate
  • Ongoing project goal metric
  • Post-launch metric

They also talked about where they were having challenges and got input from the group, such as knowing what they wanted to measure for their project, but not being sure how to measure that information.

Continue reading →

Invite ‘Special Guests’ to Community of Practice Meetings

1 Comment

Continuing in the series of how to keep a community of practice engaging, for our PM Club, we’ve had a number of ‘special guests’ that have led to interesting conversations.

We were lucky enough to have Rich Mironov present to us one time, which led into an interesting conversation. We followed up that conversation by reading another one of his blog articles that related to that conversation, and continuing the conversation on our own.

Examples of other special guests have included:

Continue reading →

Use “Vote & Discuss” for an Engaging Meeting

1 Comment

To encourage engagement in a book club or a community of practice meeting, have everyone vote before you start a conversation.

It’s a lot easier for people to agree with what everyone else is saying, or just stay quiet, but if they have to vote first, then you can have more conversation about where the group has variances in how they voted. 

Depending on what tools you’re using, you can vote anonymously, or you can have team members vote in such a way that you know who voted for what. The advantage of the latter is that you can call on people to ask them why they voted the way that they did. Of course, you don’t want anyone to get defensive or dislike the workshop, so this will depend on the topic and how close-knit your group is. 

Continue reading →