Tips from the “product guy” in a company
I started formally learning about product roughly 2 years ago and found a true passion. I also fortunately (or unfortunately) went straight into managing products at bootstrapped startups. While I’m still new to the game, I’ve recently found a bit of clarity and hope to share some tips for anyone just getting into or exploring the field. Note: This post is most helpful if you’re the only product person in the company with an outsourced dev team.
- Own the product
I’ve been caught asking the question, “Am I actually doing product management?” Well product management is typically only one part of what you’re doing, which is why your team just calls you the product guy or girl. First step is to accept the fact that you have to do everything related to the product.
For example, I perform product interviews, pull out themes from feedback or interviews, create mockups, create designs, create prototypes, get feedback on mockups/designs/prototypes, write product requirements/feature stories, organize releases, manage product development, test new features, create messaging for product marketing, and more. Once you’ve accepted that you are the product, decide what are the core aspects you need to control and then push as much of everything else off your plate as possible. I don’t always stick to this advice because usually others are unreliable and don’t move fast enough. Also, pushing things off of your plate is directly tied to resources available and bootstrapped startups don’t have many. In that case, I’ll quote my mom’s advice during my childhood. When I didn’t like something, I’d go to her and say “that isn’t fair.” Her response was the same every time, “Life’s not fair.” Not much changes in that regard so suck it up!
2. Define your workflow
If you’re the only product person in a company, you don’t have any workflow because it most likely doesn’t exist. Don’t mix this up with the engineering workflow, which is one part of your workflow (although you may have to define this workflow as well). It’s daunting and exciting to set up your own workflow, but either way, it’s incredibly valuable and necessary to make you efficient. You probably won’t be able to define your complete workflow until you’ve been with the company for 3–6 months. I’ve iterated quite a few times on my workflow and continue to do so.
You can get a head start though by putting some simple processes in place. A few examples are 1) performing product interviews, 2) getting feedback on designs/mockups/live product, and 3) communicating new components/features to your users. All of these processes tend to involve scheduling, messaging, etc so templates help a lot and save your brain power for the fun stuff.
3. Optimize communication
This applies mostly to people that work with an outsourced dev team. It’s difficult to keep everyone on the same page and push the passion of the product to your devs especially working with an outsourced team. In reality, as much as I want them to listen to me, read the extensive requirements I wrote, and pay attention to all the details in my prototypes, they’re going to selectively read/pay attention to any or all of these things.
To make sure they take it all in, you have to find the right communication mix to make sure they hear everything. For instance, while we use a tool for agile project management, they still don’t always follow the order of the stories in the queue. To help, I now write a weekly doc that outlines the focus for that week. It seems redundant with a prioritized list of stories, especially when I have links to the stories in the weekly doc, but it gives them clarity. This little bit of extra work makes all the difference. I spend less time managing them and more time on my own work.
4. Create a roadmap
When you’re the person in-charge of the product, you’re always thinking about every possible way to make it better. Naturally, new ideas lead to questions about prioritization and force you to question everything. The only way to avoid questioning yourself on a daily (if not hourly basis) is a roadmap of the next 3–6 months. It doesn’t need to be extremely detailed with exact dates, but it must outline the components and/or features in releases for at least the next 4–6 weeks. I usually bucket anything beyond 6 weeks into Short Term (6 weeks to 3 months out) and Long Term (3–6 months out). You’ll definitely make changes to features during development, but these should not change the core components and/or features that take place. Making major changes to upcoming development causes issues especially if your engineers are waiting for feedback and decide to jump ahead.
With a roadmap, you can maintain focus and keep your priorities straight. Stash all those great ideas and then evaluate them at the right time in your workflow ;)
I hope you find this helpful or at least thought-provoking. I’m always open to feedback or new ideas on anything product so please provide any comments below. Thanks!
