Surf Roots, Software Thoughts

I’ve been a product manager (PM) at Redfin for almost a year now, and I’ve learned some really valuable things. My bosses, a lead product manager and the director of products, have been incredible mentors, and I wanted to share some of the advice they have given me along with some of the things I have learned along the way. I also wanted to highlight a few points from a book that also helped me learn how to be a good PM, though I’m not sure if I’m a good PM ;).

Research
When you’re designing a product, you need to research. I’ve talked about this a lot in previous posts, so I’ll summarize my previous post very quickly. You need to understand your demographic, and you need to understand the problem that you’re trying to solve. If you don’t fully understand your problem, then you’ll very likely create an unsuccessful product. Talk to your users anyway you can – over coffee, via online surveys, via focus groups, etc. I can’t begin to explain how important this is. Do it! I didn’t research Cellarspot enough, so I designed a website that is barely used.

Documentation
The type of documentation that you’ll have to produce really depends on the situation. Generally speaking, if you’re at a larger company, then you’ll probably have to publish documents about the business requirements of a product, the specifications of a product, and the ways in which a product will look (wireframes). If you have to draft these documents, then think critically about their audience – will programmers be reading this? Will executives be reading this? Etc. Make sure you get these documents reviewed by a peer prior to sending them to your boss.

If you’re at a smaller company, then you probably won’t have to document things as much. I’ve heard of certain startups drawing wireframes on the whiteboard, taking a picture of it and writing a quick description of the features, and then sending these two things off to a developer.

Generally speaking, I think it’s far more agile to draw some whiteboard wireframes, write some quick descriptions, and then send these off to a developer. However, I do believe that documentation is very important. Documentation facilitates review, and I believe that review is usually a good thing. That’s not to say that documentation is necessary for review, though. Documentation also makes it easier for a developer to mimic your vision of the product. I would document things if I were told to, and I would decide on a case-by-case basis whether to document or not if I were to make the decision myself.

I’ve written a lot of documentation at Redfin, and I believe that most of that documentation was necessary. There have been certain times when I thought the time spent on a certain document was wasted, but for the most part I agreed with the decisions my bosses made to document things.

Working with Others – Meetings, Reviews, Etc
As you’re researching, documenting, or just thinking about the product you’re trying to build, you’ll work with other people. Depending on the company, you might be in constant iteration with your boss. Regardless of the company, you’ll have to hand things off to a developer and speak to at least a few people about what should go into the product. Be prepared to be in charge of these interactions. You’re in charge of managing this product, so be prepared to be in charge of meetings, reviews, etc. You should be prepared to do a few things. First, be prepared to explain your current thoughts and ideas. Be prepared to discuss alternatives. Be prepared to ask questions, and make sure that the questions you ask are well-formed. Be prepared to be in charge of organizing meetings, and be prepared to be in charge of making sure those meetings move towards a solution. More to come on what to be prepared for …

Your Idea and the Alternatives
While designing your product, you’re going to run into a few forks in the road, where there are a few different options and only one option can be chosen. Go into meetings with a choice and reasoning for your choice. In my meetings with our CTO, I would present all the options and brainstorm them while in the meeting. I should have brainstormed the options on my own time with peers and presented my decision to our CTO with a detailed explanation and reasoning for not choosing the alternatives. It’s very easy to fall into the trap of putting decision making off, so make sure you’re either making good decisions or asking questions that will help you make a quick and good decision.

One of the products I worked on at Redfin was very, very delayed because of the way I interacted with our CTO. I kept expecting him to make a decision with research that I would present to him, when really he wanted me to make a decision and review my decision.

Take charge; make decisions – just make sure the decisions you are making are well thought and that alternatives have been addressed.

Too Much Data … Can’t … Synthesize
When researching a product, it’s very, very easy to get too much feedback. It’s also common for feedback to contradict other feedback. For example, your CEO might say that he or she wants features A, B, and C and not X, Y, or Z, while a customer might say that he or she wants features X, Y, and Z and not A, B, or C. It’s very easy to get overwhelmed when synthesizing research and feedback. When this happens, take a step back and revisit the problem. Clear your head over the weekend or spend a weekday working on something else. Revisit the problem with a clear head, lay all the options on the table, and make a decision. Again, get others involved by presenting alternatives and reasoning.

I organized a meeting with our CEO, CTO, director of products, director of marketing, and a few other people, and I would say that there were at least five contradicting opinions in this meeting. I didn’t know what to do. I wanted to satisfy everyone’s requirements, but there was no way to do so given their varying opinions. I took some time to work on a different product and later revisited this product. I wrote all the options on the whiteboard, made decisions on contradicting opinions, and prioritized the list of features. I’m still worried that the decisions I made might annoy certain people, but I try to remind myself of the following thought. At one point I had all opinions, feedback, and data in my mind, and the presence of those things naturally affected the way I see this product. Even though I may not have incorporated certain opinions in my list of features, I at least incorporated those opinions in my decisions.

Schedules
Often times PMs are in charge or setting schedules. Make your schedules milestone-oriented. Bucket various work items into milestones and set dates for those milestones. Some example milestones are code complete (all code written), content and design complete (all content and design elements have been included in the product), test ready (your product is ready for testing), zero bugs (all bugs either triaged (priorities changed, assignments made), punted (moved to a later release), or fixed), and release to world (your product is launched). Schedules are much more manageable with fewer deadlines, and bucketing work items into milestones makes it easy to have schedules with fewer deadlines.

When picking deadlines for milestones, make sure your deadlines are based off of feedback from the owners of the work items for each particular milestone. Top-down schedules (schedules defined by a PM and followed by stakeholders) are more prone to inaccuracy and generally create a stressful environment. Talk to each stakeholder and ask them how much time they need to finish their work items. Think critically about dependencies as well – often certain work items will depend on other work items, so these dependencies should be included in your schedule deadlines. Once you have an idea of how long a milestone will take, send an email to all of those involved in that milestone and ask for their confirmation. Bottoms-up schedules are more likely to be accurate and also make the PM seem more like a coordinator/leader than a dictator. Bottoms-up schedules are less likely to be rushed, and therefore the quality of your product is more likely to be higher. A possible criticism to a bottoms-up schedule is that stakeholders such as developers, system engineers, and marketing analysts will be lazy and set dates too far in the future. Hopefully you work with people who are passionate about their work, but if they aren’t, then you’ll have to motivate them. More on motivation later …

Schedules are insanely important. Setting schedules makes your product more likely to move forward at the fastest possible rate, especially when the schedule is defined from the bottom up. Spend time creating a schedule, and make sure that everyone involved in the schedule understands it and agrees with it.

Motivation
It’s easy for large projects to drag on and become uninteresting. It’s also common for coworkers to have different motivations. For example, it’s not uncommon that a PM finds a particular feature very interesting and fun, but a developer finds that same feature to be boring and uninteresting. In cases when a stakeholder is uninterested, it’s your job to motivate them. I haven’t had to do much of this at Redfin, but I can make a few speculations. First, be kind, positive, and pragmatic. I’ve seen first hand how one person’s energy can affect those around them. Create positive energy, not negative energy.

Be generous and thoughtful. Bring your team to a happy hour every now and then. Buy your team a nice lunch. Ask your team how their families are or how their weekends were. Again, create positive energy. Tell your team how awesome their work is – how fast their code runs, how beautiful their design is, or how badass their recommendation system is. Also, always ask if there is anything you can do to help.

Take the blame. If something goes wrong and it isn’t clear who is at fault, then take the blame. You might not necessarily be the person who erred, but take the blame anyway and do what you can to right the wrong. Your team will appreciate this, and at the end of the day, it doesn’t matter who is wrong. Taking the blame makes everyone feel better and allows things to move forward.

Perhaps some people might argue that these techniques are all brown-nose-ers. I simply disagree. Compliments are powerful and make people feel good, and people that feel good are more likely to kick ass, even if they’re burned out or uninterested.

In Summary, Be a Leader
Most of the advice I have just explained really comes down to simply being a leader. Lead your team in a positive, thought-driven way, and do the best you can.

Leave me a comment if I’ve left anything out or if you disagree with some of my opinions.

Update: Amit wrote a really good response post here (also in the trackbacks).