📹 New! Remote User Testing - Get video + voice feedback on designs and prototypes
Read more
Product Design

How to Approach Product Management for Bots

Conversation with Veronica Belmont, PM at Growbot
How to Approach Product Management for Bots

In each entry in this “conversation” series, I talk to a designer/product manager/engineer on a topic. I want to make basic practical skills education transparent and free.

Image credit: Javier Diaz

Today I’m talking to Veronica Belmont, a product manager at Growbot. Growbot helps you appreciate your colleagues and is specifically for teams which use Slack and Microsoft teams for communication. She joined as the first product manager and employee.

What is your role as a PM since it’s such a small company?

Right now I primarily own the Microsoft Teams side of the product, though I also work on Slack features as well. I work a lot on the design of new features, develop the voice of the bot and also help to manage the roadmap. It’s very hands on and a lot of fun.

How is developing a bot product different than a webapp or an app?

Working for a bot is a very different type of interaction than working for a webapp or an app. It’s a space that’s still developing and there’s no standardized way of doing things. There are so many differences between tools, platforms, and design. This lack of standardization brings a whole set of challenges with it.
We have to think about all the potential interactions a user could have with the bot and how those will play out. One of the unique things we face is that company cultures are very different place to place, so we have to think about all the ways that our bot could help to solve the issues they have.

What are the challenges in the bot space?

The biggest challenge is getting a user to understand how the bot works. Users come in with a lot of misconceptions about how bots are supposed to work and how they should interact with bots. That’s one of the problems with the lack of design convention in the bot space is that people just want to speak to it naturally, which is totally understandable. However, that’s not how every bot works.
It’s the bot designers job when they are onboarding the user to convey how the bot works, what it’s going to accomplish, and what you need to do to get it to do the things you want to do.

The other thing is that it’s completely different from platform to platform as well. A Facebook messenger bot is completely different from a bot in iOS or a bot in Slack or Kik. All the platforms have different functionality. They all have different feature sets or capabilities. It’s up to the job of the designers, PMs, and engineers to figure out how they can get the most out of it.

How do you set expectations about what the bot can do?

You want to strike that balance of giving them enough information but also getting them into the product to use it as quickly as possible, because there are so many opportunities for them to drop off and churn. So it’s basically looking at the data and figuring out what the successful teams are doing and trying to mimic that with our new teams. We are constantly trying to redo our onboarding process and figure out where the drop offs are and refining it as much as possible.

Just think about how you use software, or a web app. If you can’t figure out how to make it do what you need to in a very short amount of time, you’re out of there and on to the next product. The window of opportunity is very small. Especially in our case the way our bot gets adopted is a very bottoms-up approach. Our buyer persona is ultimately HR but usually they are convinced by an internal team using it. If the VP or CTO at a company decides they need a recognition tool, and that Growbot is the one they want to use, that’s awesome. But it’s typically the engineering teams, or the customer support teams, that are really driving the engagement.

Could you show me how onboarding in your product has evolved?

Sure! This is our old onboarding and below is how it’s evolved today. What we have changed currently is helping them make us part of channels and also adopting it effectively in their company.

This is the newest version:

What are the metrics you measure?

We primarily look at engagement in DAU’s and MAU’s. In our case specifically props/ kudos given and reactions added.

How do you think about retention so the user doesn’t forget about you?

Striking the right balance for messages is challenging. We want to keep users engaged, while also not driving them insane! Giving them the option to mute certain messages and notifications is key.


Right now we have 10 min and 24 hours recaps. Essentially, you’ll get these recaps when you send and receive kudos so you know who has interacted with them (and how much).

We also have weekly channel recaps, which the user can set on and off. These highlight the most popular kudos that have been sent, and give users an opportunity to interact with them again if they missed them the first time around!

We definitely want to do a lot of customization features because cultures differ vastly from team to team. We also have a feature called Growbot Lite, which is a very quiet version of the bot. That still does all the tallying?—?it just doesn’t post any messages in the channel and it doesn’t do any channel recaps. It’s just a very quiet way of gathering the data so people can use and access it, but not have to interact with the bot quite so much. Obviously, we don’t really want people to turn that on, but if it works for them and they are using it then that’s good. We have some super engaged teams that have lite turned on because that’s just how the their culture works.

What tools/ software do you use to prototype the design and interfaces?

There are a lot of tools that are helping bot creators figure out conversational design. One of them is called Walkie, and it’s my favorite for Slack. It allows you to create conversational flows from a bot and user perspective. And we use Sketch as well for design too, especially since there isn’t a Walkie equivalent for Microsoft Teams (yet)!

How do you think of the bot voice and tone?

We are still working on finding a very cohesive voice. The first thing I did when I joined was to create a written style guide for the bot which has examples of how the bot will respond to things, what tone it will use, and what adjectives describe the bot.. It’s important to have a consistent voice so users know what to expect.

How are Microsoft Teams and Slack different?



They are extremely different platforms. Right now Microsoft Teams is still very young, so there is a lot we can’t do yet.

The biggest difference is that you have to mention the bot in order for us to pick it up in Teams. We aren’t able to scan for keywords in the same that we can in Slack. That’s a little thing which could potentially hurt engagement a lot because people have to think about one more thing in order to get the bot to interact. The other biggest difference is the lack of emoji reactions, which are pretty integral to our design. But they have a lot of nice features too, like the ability to have tabs for your bot, which I can use to post Release Notes and other product updates.

How do you iterate and get feedback from customers?

Every conversation with customers is valuable. It’s really about what they are asking for and seeing if that is what other teams are asking for as well.

Personally, it took me a long time getting comfortable asking people for feedback. And this is coming from an extrovert who has spent the last ten years interviewing people about all sorts of stuff! Maybe I take it more personally now. The role of product is to take feedback and to turn it into something constructive. It’s hard especially when you are talking about features which you worked so hard and built and launched and worked on with your team. It can be challenging.

There’s one feature that I’ll definitely mourn — GIF Thanks. Our CTO came up with the idea, and I absolutely loved it. Essentially, you could send an animated gif to someone after you received kudos from them. It would show up as a message in a thread. However, no one was using it! We switched it to a simple text-based “thank you” and it worked much better. It’s a good lesson that no matter how cool you think a feature is, it might not fit in with the way people like to use (or expect to use) your product. We still use it on our company Slack team though!

This post was originally published on Romy's Medium profile.

Get started with Marvel Enterprise

Get started with Marvel Enterprise

Some of the worlds most creative companies use Marvel to scale design across their organisation.

Get started with Enterprise

Romy is the founder of Flowcap, where she publishes content on product management, design and data with the aim of making real skills transparent and free. Previously Senior Director of Product at Visually. Has also taught at General Assembly.

Related Posts

Successful products from the Soviet Union that were created in isolation to the rest of the world.

Speed up your design process with this UX research framework that will help you collaborate with researchers.

Some of the best PMs I know make their decisions based on first principles. A first principle is a “basic, foundational proposition or assumption that cannot be deduced from any other proposition or assumption.”. An example of one that we use for our developer platform team are that “all platform features should be like Lego blocks”, meaning that developers should… Read More →