When Your Colleagues Are Your Customers: 8 Tips for PMs Building Internal Tools
In four and a half years in product management at BuzzFeed, I’ve spent time working on both consumer-facing products and internal tools. Both are fun and challenging, but it’s building internal tools that really makes my heart sing. Here are some tips that I’ve learned from building software for the people who create, edit and distribute BuzzFeed content.
Tip #1: Embed with the people who use your products
When you build internal tools, you are in the fortunate position of having users who are also colleagues. Most product managers don’t have this luxury. Take advantage of it!
When I send an email or wait to hear from users, the feedback comes in a trickle. When I hold “office hours” in their space and cajole people to come talk to me, the quantity of feedback increases. When I sit with someone and watch them work, that’s when the feedback comes pouring out. Set aside time to shadow users.
Watching people do their work is the best way to make sure that you really, truly understand the ins and outs of their job. A deep understanding of your stakeholders’ workflows can help you nail the details of an implementation. It’s also a great way to identify easy, small changes you can make that will make people’s day.
Tip #2: Combine big projects with quick wins in your roadmap
It can be great for your team to mix in some simple quick wins that users will love, even if they won’t really move the needle on team or company KPIs. You can earn a lot of appreciation and goodwill from users by taking something that used to be tedious and painful and making it easy. And it can be fun for the team to crank out a few fairly easy features that people go bananas for.
In one sprint, an engineer in our production tools group built a dropzone that automagically parses the track title and track ID of stock audio files from the Warner Chappell catalog so that video producers didn’t have to type the info in manually — some long videos might have well over a dozen different audio tracks.
It’s not as if we thought this feature would blow the doors off of productivity and 3x the number of videos a person could make. But manual data entry is booooooooorrrrring. We’re thrilled when we find fairly simple way that we can automate a tedious task and make people a little happier at work. When we demoed this feature for producers, they screamed very loud and I’m pretty sure one guy shouted “HASHTAG BLESSED!” It was a delight.
The key is that you can’t let these quick wins take over the whole roadmap. They should be projects that you know will be simple from a design and engineering perspective and very popular with the people using the tool.
Tip #3: Write your launch email when you’re in the planning phase
Even as early as the planning phase for a feature or product, I imagine myself writing the launch email or running an onboarding session.
It’s pretty easy to assess whether I’m going to be excited to tell people about the amazing new thing they are getting or I’m going to be stressed about rolling out some new thing that they are going to see as a hassle or an imposition.
In my head, I imagine every person using a tool as a little ball. For the launch, you need to move the all the balls from Point A (their existing tool or workflow) to Point B (the new version you are going to give them).
If the new thing is way better and easier, then it’s like letting balls roll downhill.
It really doesn’t take much effort to get them to where you want them to be. You build a good thing, you train them how to use the good thing and they clearly recognize the benefit of the good thing. They embrace it and take off. The better the thing, the steeper the downslope. A very good sign is if people you haven’t even onboarded yet are using or asking to use what you’ve built.
If the new thing is a pain in the neck, then it’s like moving the balls up a hill.
It will take a huge amount of effort from you to push, encourage, cajole or berate everyone until they are at the top. If you get tired and take a break, you will look back and realize everyone has rolled back to the bottom of the hill because they do not like Point B and want to remain in Point A. The worse the new thing, the steeper the upslope. A very steep upslope is not fun. Ask Sisyphus.
It’s important to make clear that there are totally valid reasons to launch something that you know is going to be an imposition on the users. Maybe you need additional metadata that will allow your tools to do some amazing powerful new thing. Maybe you need to fix an essential security issue. There are any number of good reasons to work on a feature that won’t be received with great joy by the people who use your tools.
A sad-but-true fact is that many many people don’t really care all that much about features / workflows / requirements that are good for “BuzzFeed” or good for some other team or department. They care about features that have an obvious benefit to themselves. So try to figure out some way that the launch makes their life a little better so you aren’t trying to roll 200 balls up a steep hill.
Tip #4: Identify your most product-minded users
You’ll often find that some subset of people who use your products have lots of ideas about how to make them better.
These product-minded users aren’t necessarily your key stakeholders but they’re incredibly helpful people to have close relationships with. They are often willing to give you feedback on early designs, to be beta users for a new feature or to share their thoughts on prioritization.
Seek out these product-minded humans then ply them with treats and shower them with compliments until they become your friend.
Tip #5: Pay attention when your users hack your tools. They’re telling you something
If you realize that a large set of your users are using your tool in some odd way that isn’t what they should be doing, pay attention. There is some unfulfilled need that they are inventing a solution for. If you figure out the problem that they are trying to solve with their hack, you’ll wind up with ideas for the product roadmap.
Tip #6: Don’t go silent if you aren’t going to prioritize something
If a stakeholder asks for something and you aren’t going to put it on your roadmap, don’t nod your head and say “mmmmm” and then disappear. It’s hard to say no. It can be tempting to be vague, leaving stakeholders with the impression that you’re going to work on their request. This might be less unpleasant in the short term but it’s bad for your relationship in the long term. If you aren’t going to prioritize something they want, you should tell them in a straightforward way why you won’t.
It’s useful if your stakeholders already have a sense of what you are working on and why, so you can explain how this new idea isn’t higher priority and your team doesn’t have time for it at the moment.
Tip #7: Own onboarding and launch announcements
Users are like baby ducks. They imprint on the person who teaches them about a tool and that’s who they go to with questions and feedback. You want those baby ducks to imprint on you or people on your team so that you hear all of their questions and feedback! Your team should own launch announcements, no question. You should also be a part of onboarding or training where possible.
Baby duck users also imprint on workflows. It’s worth teaching people how to do something properly, because information about how to use a product is often shared casually peer-to-peer from current employees to new hires. You want to make sure that if a baby duck turns to their neighbor (an older, more experienced duck) and asks a question about how to use the product, the older duck gives them the answer you want them to give and doesn’t give them some bad info that is not, in fact, how anyone should be using the tool. Teach those baby ducks right and they will grow up to pass on their good habits to future generations of ducks.
Tip #8: No one reads the documentation
This is an exaggeration. Some small percentage of people are goody-goodies who read their emails and follow instructions and click through to the awesome user guide you created. But a lot of people are never going to open all the careful documentation you have prepared. So make the tool itself simple to use and hard to mess up. It’s also easier to teach the baby ducks if you don’t have to sit them down for a two-hour tutorial where you explain the nuanced differences between Option A and Option B and Option C and Option D and Option E because they probably do not care and won’t remember.
Have you built internal tools for your company? What tips and strategies do you have for building first-class products for your colleagues?
By the way, BuzzFeed Product is hiring! Come work with our amazing team. If you live in LA and want to talk in person, send me an email! alice.dubois@buzzfeed.com
