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 understand their current process, then we can work with them to figure out how a software application could make their lives easier. So we might ask them, would it be helpful if we could use your phone to scan all your ingredients and then make a list of recipes that you could make? What if we had some sort of rating system so that your favorite recipes rank higher than those that were only so-so?
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
Assuming we’ve found a set of features that makes business sense, we then pass the requirements over to the design and engineering team to start building. While the app is being built, we constantly keep an eye on its progress and make sure that it’s meeting the requirements and business needs. I’m sure this drives the engineers crazy having someone “bossing them around” but it really is a necessary function, otherwise we may end up building the wrong thing that will fail in the marketplace.
Keys To Success
In the old days (the 90’s and early 00’s), the 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?
As with anything, it’s a matter of supply and demand. On the demand side, tech companies are now realizing that a poorly defined product is the quickest way to a disaster. It results in very slow development of a product that no one wants that isn’t profitable. On the supply side, it isn’t easy to find someone that has all the necessary skills that a good product manager needs. Not everyone is able to survey customers, distill insight from these interviews, translate that insight into a set of technical requirements, understand which features are technically feasible, make legible sketches/wireframes, research business feasibility, make financial pro-formas, make business plans, manage tech teams, and clearly communicate.
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
