So you work at a tech company and there are “Product” people, but you’re not sure who they are or worst what they do. Well, it seems like the definition of a product person has a lot of grey area depending on where you work. Quora has plenty of discussion on the topic, but to quote Adam Carolla “I don’t have any insights, but I do have an opinion.” I’ve been doing online and offline product for 15+ years so I do have an opinion.
What Product Doesn’t Do
Unless you work at Google or some small start-up that pumps out awesome apps, chances are you don’t code. And you probably don’t design. Knowing how to use Balsamiq doesn’t make you all that creative. So if you don’t code or design, what value are you adding? Well, if say that you do strategy or you are the idea guy, you probably aren’t a product person. Product people shouldn’t do things they’re not supposed to or necessarily good at (code, design, etc.), but rather focus on what they should do and do it well. The other golden rule for me is, “Just because you can, doesn’t mean you should…”
What Product Should Do
If you’re in product, you need to “own” the product. This means that you should take responsibility of the process from inception, user testing, development, more user testing and shipping the final product. Taking responsibility doesn’t mean you control everything or do everything. What it does mean is that you define and understand customer needs, provide the vision and requirements for functionality, are involved in the process cross-functionally and lead the team. You need to be like Peyton Manning (pre-neck injuries) and be able assess the situation and call an audible. In addition, the product needs to be shipped on time and on budget. If you were thinking, “That’s not my job” for any of these parts, maybe you should
be a project manager try harder. Below are some of my thoughts of what a good product person should do.
Know (Learn) How to Write Requirements
Be able to write good product requirements and specs. This doesn’t mean an outline with bullet points or filling out some sh*tty PRD form that someone created where you fill in the blanks. Even in this day of Agile, you still need to be able to write specs. If you are dealing with backend tools that are complex, writing stories, tasks and ACs may not be enough. Sometimes you need to write documentation that’s detailed.
With complex products, sometimes I still write fully specs. Writing full specs forces me to think about the product holistically and at a level of specificity. My goal is not to do waterfall, not to have the developers read the doc, but more for me to fully think about and understand the product and functionality. What I then do is breakdown the specs into iterations, stories and tasks by priority and rank. There’s nothing better than being able to speak about your product in detail to anyone on the team. I provide the specs to the developers while they are coding and provide page references so they can read only what’s relevant to them.
If you don’t know how to write or create specs, ask someone to help you. Don’t rely on brainstorming meetings; this is a skill that is learned by doing. Brainstorming and collaboration help to make the product, functionality, process, etc. better, but you’re the product guy, and you better have some idea of where to start and what to do next.
Before all you Agile purists jump all over this, my point here is that product people need to be able to know their product inside and out regardless of the process. Even if you don’t write full product specs, you should be able to do so. I’ve seen way too many product people who can only write “As a product owner…blah, blah, blah.” and can’t explain anything in detail. Know your product well enough regardless of how you document requirements. End the stand-ups on time and cut down on the number of parking lot meetings.
Define the Core Product
With every product, be able to determine the core functionality. Without a doubt, things always come up during a project and decisions have to be made. In the event you have to make trade-offs or cut scope, you need to be able to know that whatever you ship consists of the core deliverables. I always try to plan and focus on the core of the product in the first iterations of the project. I do this for two reasons. The first is typically the core part of the project is the hardest or most labor intensive. As a result, I want to ensure that we’re working on the most important parts of the product first to ensure that no matter what happens we can deliver core functionality. The second reason is that you want to try and have a downward LOE slope for the project over the iterations. If you plan to have a piece of core functionality with a high LOE toward the end of the project, you’re running the risk it won’t get delivered. Know what are your vitamins (nice to haves) and what your pain killers (need to haves) are.
Understand Your Customer
Unless you’re a Steve Jobs, take the time to understand what your customer needs and expects in context. I believe the best way to do this is to do your homework up-front before any coding starts and create hypotheses and try to validate them. Test early and often. This is The Lean Startup approach and I’m not going to get into the details as there’s plenty of information already available. If possible, get out of the office and talk to your real or potential customers to get real feedback. Be willing to admit your initial ideas or concepts may not be good. Everyone has an ego (varying degrees) and it’s hard to admit you’re wrong, especially when you’re emotionally attached to an idea or concept. Make it a rule to let the user feedback be the deciding factor, not your opinion.
Manage the Trifecta
My belief is that the role of product sits in the middle of three forces that are many times diametrically opposed. These forces are SEO, UXD/Design and revenue. As a product person (Jedi), you will need to fully understand these forces, what role they play in the company or your product and how to make decisions and trade-offs between them. IMHO, I think the best you can do is to achieve two out of the three, but not all three and if you believe Meatloaf, “Two out of three ain’t bad.” For instance, if you have a content heavy site, your depth of content, content silos and URL structure is very important to drive organic search engine traffic, but may not present the best user experience. A great site for the user may lead to less revenue and not support SEO goals. A pure revenue generating site (lead gen) may have a horrible user experience and not have any organic traffic.
There are no right or wrong answers here. You just need to be honest and prioritize accordingly. If revenue is your highest priority, then don’t pretend that you’re going to do everything you can to provide a great user experience. Product people need to be able to sift through all three elements, along with the associated risks and rewards, and then account for them when planning the product.
Communication is Your Friend
We all know what communication is; maybe some of you even majored in it. However, most of us are not very good at communicating. As a product person, you need to be the hub of communication for the team. Spend the extra time and effort to let everyone know what’s going on, why we are doing what we are doing and how everyone’s part ties into the big picture. Don’t think that just because you’ve talked about it once and the stories are in Confluence, JIRA, Rally or some other repository that people are actually going to go there are read what you wrote. The tools are just tracking mechanisms or repositories and do not serve as a substitute for human intervention. This is your product and it’s your responsibility to make sure ideas, concepts, visions, etc. are communicated to the team.
Do the communication in person, not via email or IM. Don’t be lazy, get out of your seat and walk over to people and talk face to face. This not only solves problems quicker, but also creates a working relationship and bond between team members. I have this saying about how many miles you’ve walked in the office today in regard to how much you’ve taken the time to walk over to people’s desk and talked.
Learn how to tell a story. I’m not going to get carried away with this as the intent is not for keynotes or presentations, but rather for your project. This can be done in many ways. For instance, during the kick-off or weekly meetings show mock-ups, roadmap, sitemaps or demos and facilitate discuss and feedback. Have the ability to provide a holistic view of the product, but be able to talks to specific details at given times throughout the project. The concept here is similar to “Think Globally, Act Locally.”
In my experience, developers appreciate it when you can explain how an entire process or functionality will work, but have the ability to focus on a specific aspect in the current iteration. This way developers can take the information and determine the best way to code. I’ve heard too many developers say that if they only knew something ahead of time, they would’ve written the code differently. Don’t waste your developers time, be descriptive, not prescriptive, and give them enough of a runway to determine how to successfully land the plane.
Build Your Toolbox of Skills
Take the time to learn skills that are valuable no matter where you work. You absolutely need to learn things that are directly related to your current job, but if you only learn things that are propriety to a company and you go to another company in an unrelated field, those skills may not translate. After working at Edmunds for 7 years, I learned a lot about automotive data, but unless I go to another company in the automotive sector, the data knowledge itself is useless. However, if you learn how data is structured, the services or APIs used to translate and transfer the data, and how the data is used to create functionality, this is valuable no matter where you work. You want to be known for your individual product skills, not just for what the company is known for or the sector the company is in. Don’t get pigeonholed in your career.
You should also learn a wide variety of skills outside of your direct area. Take the time to learn the sales role, SEO, affiliate program, customer service, accounting, legal, reporting, etc. Getting to know the various people in your company and what they do day to day may not help you immediately, but this helps you get a better operational understanding of how your company works. You don’t just become “cross-functional” overnight, it takes time to develop relationships and a thorough understanding of how each aspect directly or indirect affects your product.
Make it a point to stay up to date with what’s going on in the technology space regardless if it’s directly related to your current position or not. There’s always more happening outside of your area than within your area. You want to be able to be aware of the current trends in the industry. I even download all kinds of apps just to see how content is being displayed, the navigation paths being used and design implemented.
Read. Read more books, articles, blogs, etc., just read more. Yes, it takes time, but it’s well worth the time spent. Once you’ve read about what’s going on, then have discussions with others and exchange ideas. Having conversations about what’s going on is a great way to discover opportunities for your company or the products you work on. Start to connect the dots and use these ideas to create better products and experiences. Here are some sites that have great information:
Life moves pretty fast. If you don’t stop and look around once in a while, you could miss it.
These are just some of the things that good product people need to do, but certainly not all of them. To be really good in product you really have to be invested in the process and have pride of ownership in the resulting products. You have to have vision and the ability to plan, but you also need to execute and deliver. Being good in product is a skill that constantly needs to be exercised and updated.