My Top Product Learnings
I started my Ruby on Rails class this week! And eight hours into my first assignment, I just hit submit, poured a glass of wine, and started this post. So far this week, I created a few modest repositories in GitHub, learned about nested data structures, and wrote a program referencing multiple classes. This is going to be hard - and awesome.
As I mentioned in my last post, from my years in Product I have some sense of what kind of developer I want to be. And before I disappear into programming, I want to share a few quick lessons I've learned from my years in Product that I hope to reference along the way.
1. Earn Your Team’s Respect
The most critical first move for a Product Manager is to meet with your team members one-on-one. Usually this means a group of designers and developers. Then remain available to them - for questions, for coffee - nothing else should trump your schedule more rapidly. A Product Manager must have the respect of the team he or she is managing. If designers think you are too critical, you nit pick, you don't get their process - you lose them. If developers think you are asking them to do things that are unreasonable, or that you don't bother to get how they code and make decisions, you'll get constant pushback.
Sometimes developers will spend a lot of time trying a single approach - or go down a rabbithole. I have had the most success on teams where my developers come to me for help rather than avoiding telling me about their issues. Product Managers should position themselves as the voice of reason rather than a stressful presence focused solely on time and output. In short, you need the respect and buy-in from your team to make anything happen effectively, so start that early.
2. TREAT PROCESS LIKE A PRODUCT
The primary responsibility of an effective Product Manager is to keep your team humming and never ever ever block their inertia. This requires constant prioritization and even more diligent communication. However your team operates, leave room for revisiting processes and modifying them - even discarding the ones that don’t make sense. The best lesson I learned from a former boss is that process should be iterative, just like your products.
It is not super difficult to identify a process that is broken. Key indicators include lateness or absences from key stakeholders, bad attitudes or vibes, missed deadlines - in short, they are fairly obvious. But we often stick with this brokenness despite the pain it causes us because we get overly attached to what's there and are intimidated by a new blank space. Teams change (hopefully by growing if you're meeting success!) and you must evolve your processes accordingly. One great tip - frame every new idea as an experiment, one that you will try for x period of time, reassess as a group, and determine next steps. This way, you minimize fear over something new that people are certain they will hate, and you create a structure that naturally revisits processes every so often with the intent of assessing and revamping.
Bonus points: discarding broken processes quickly and replacing them with new, more effective ones is another great way to build trust with your team.
3. Be Decisive
In my experience, the most essential quality of an effective Product Manager is decisiveness. So many products fail because the people at the helm cannot move forward. This is difficult - it's tempting to share sentiments of doubt or ideate far along in the product development process. But if you have good structures in place - like engineer involvement early on, user testing throughout, strong analytics to inform performance, an easy-to-implement a/b test framework - then at some point you have to trust your gut and just DO IT.
On a more day to day level, let’s say your engineers are done with the work you've defined for them, and you realize your next project is not ready for them yet. What do you do? Find some structural work; organize a bug day; come up with a killer marketing initiative that you normally would never have the dev time to complete. Another example: if an engineer asks you a question and you're not sure how to answer, choose the answer that is the easiest for the engineer to implement and the easiest for you to undo. For example, an engineer asks - "Should I include this extra button that's on the design?" Your brain says "I have no idea if I want that or not." You say, "Nope!" If you're wrong, you can add it later. If you're right, you just saved both of you unnecessary extra work.
4. Don’t Be A Perfectionist
[Disclaimer: my most beloved experience has been in startup, where time and money are top of mind. And much of the below does not apply to hardware, or to other scenarios where you can't fairly quickly change things through software deploys or app updates.]
One of the more dangerous pitfalls for a Product Manager to fall into is perfectionism. Product Management is half creative endeavor and half project management. Your job is to make shit happen (albeit the right kind) but that involves being able to cut scope. Understand what you're asking people to build, listen to them when they say it's going to be really hard, be proactive about making it easier. The faster you can put reasonably good products in front of users, the faster you will know how they are doing and the better you can be at improving and iterating.
But, this can get HARD because it's sometimes impossible to know where to draw the line. Two key questions to ask here:
1. "Is this element critical to learn what I want to learn from this test?" For example, if including that super-cool-scrolly-thingamagig will take your developer team 2 weeks, perhaps it is just not worth it. However, if you know that your first email to the user must be well-designed and catchy, then build it!
2. "If this fails, what will I do next?" Having a roadmap of a/b (or other) tests is critical - what to do next if your test wins and what to do if it loses. Because a test is just the first of many until you get it right.
These are just four of MANY lessons I've learned as a Product Manager - more to come in the future. Now, back to coding!