In past articles, we’ve discussed the value of Business Analysts and Quality Assurance, but I’ve noticed that we have not yet discussed my own function of Product Management. Being a naturally humble person, I tend to avoid talking about myself, so I’m not surprised that it has taken this long. Nevertheless, I’ll attempt to “toot my own horn” in this article as best as I can.
Definition
So what is a product manager in a tech organization? There are several definitions out there but the one I like best comes from Martin Erickson who makes a cute Venn diagram which shows our job as being at the nexus between the user’s experience, the business’s requirements, and the technology needed. Or put more simply, we’re responsible for making sure that we’re building the right thing– one that customers want, one that will make us money, and one that’s feasible to build with the resources that we have.
Job Description
Despite the fact that I like the above definition, I’ve found that I can’t really use it to explain my job to people at cocktail parties. I get a lot of blank stares when I use the term “Venn diagram”. However, if I talk about the day-to-day job description, then people tend to “get it”.
User Experience
The first part of the job is to understand what problem the application is trying to solve, and how the user will interact with this product in order to solve the problem. So, for example, if we were to build an app that helps people figure out what to make for dinner, we’d start by asking a wide variety of people to tell us about their dinner making process. Do they look in their refrigerators first to see what ingredients they have? Do they comb through recipe books first? How do they account for which family members dislike and/or are allergic to certain foods?
Once we grasp their current workflow, we collaborate with them to explore how a software application could simplify their tasks. We might inquire if they’d find it beneficial to scan ingredients using their phone to generate a recipe list. Additionally, we could discuss implementing a rating system to prioritize their favorite recipes over less desirable ones.
From there, we put together as comprehensive a set of requirements as we can. We make a very detailed list of all the features the app has to have. So in the recipe app example, the features might include: log in, log out, create account, forget password, input list of ingredients, edit list of ingredients, input family members, edit family members, input family member allergies, edit allergies, input recipes, edit recipes, match recipes to ingredients, present meal options to user, etc., etc. These lists get very long. And sometimes they are hard to describe in text. So, for example, if I have a particularly innovative idea on how to present the recipes, I’d have to sketch it out so that the engineers understand what they need to build.
The final step in this process is to run everything by the Business Analysts who make sure that we’ve thought through all use cases, and that we haven’t forgotten anything.
Business Requirements
After we have the vetted list of requirements, we pass them over to engineers who estimate how many hours it will take the tech team to build. We can then add up all the hours, multiply them by an hourly rate, and voila! We then have an estimate of how expensive it will be to build this application.
From there, we figure out if the application makes business sense. How much can we charge for this app? Who pays? Are they willing to pay? How many people do we think will pay? And how do we reach them? This requires industry research, potential customer surveys, and an awful lot of math.
Technology
Once we’ve identified a set of features that align with our business objectives, we transfer the requirements to the design and engineering teams for implementation. During the development process, we closely monitor progress to ensure alignment with requirements and business objectives. While it might seem like we’re “bossing around” the engineers, this oversight is crucial to prevent building the wrong product, which could lead to failure in the market.
Keys To Success
In the old days (the 90s and early 00s), software engineers (coders) were the highest-paid employees in tech companies. Their skills were in high demand and low supply, therefore they were the rock stars of Silicon Valley. Product people were seen as second class citizens because they weren’t the ones being creative and building the product.
Today, that paradigm has flipped. Product managers now earn around 10% more than their engineering counterparts. Why is that?
It’s a matter of supply and demand. On the demand side, tech companies now recognize that a poorly defined product leads to slow development, an unwanted product, and lack of profitability. On the supply side, finding individuals with the complete skill set of a good product manager is challenging. Not everyone can gather customer feedback, distill insights, translate them into technical requirements, assess technical feasibility, create clear sketches/wireframes, evaluate business viability, develop financial projections, create business plans, lead tech teams, and communicate effectively.
Put another way, a good product manager is well worth the investment.
Conclusion
So why am I telling you this?
Hopefully I’ve convinced you that product management is an important role. If you’re planning to build a software product, I highly recommend that you have a strong product manager on your team. This person could be internal to your organization or they could work for your outsourcer, or both! Just make sure that you have a strong product manager (who you trust) on your team.
As I said before, I’m a humble person who doesn’t like to “toot my own horn”, however, I do honestly feel that Codestringers does a fantastic job of product management. Our leadership team is made up of entrepreneurs who understand business, we have led enough product-builds to understand consumer behavior, and we have just enough technical knowledge to be dangerous. Furthermore, we like to think that we communicate well with team members and with clients.
Give us a call anytime if you’d like to discuss further.
Christian Schraga