This is tale of two Product Managers. It tells you how you can switch to Product Manager role in much less time and how the hiring managers rate you.
Several people come to us when they fail a couple of interviews. Some proceed to the final round of interviews and they fail to get an offer. Or some just fail the first telephone interview. Others fail in the middle rounds. Remember, it takes only one question to be be answered incorrectly in order to fail an interview. So what is it that makes you sound an experienced Product guy ? Let us break it down.
Practice answers to common questions: Preparation is the key to all interviews. While this may sound trivial, many candidates often underestimate this aspect in their interviews. It goes a long way to get the role you want. But what exactly is preparation, you may ask ? It involves writing down answers for common questions like: how do you collect requirements, how do you prioritize them, who do you interact with as stakeholders etc. It also involves creating stories based on SOAR/STAR/CAR frameworks for questions of the type “Tell me a time when..”. If you are appearing in person, practice and be ready for panel interviews, as these are becoming more common. These are just a few examples. But I think you got the gist.
Never answer in black and white : Newer candidates often give away their naivety by giving simple yes/no or A/B type of answers. Experienced Product Managers don’t get stuck up in a single answer. They always give multiple answers and can come up with justifications for their chosen answers. To give an example, do you always address requirements from your high-value customers ? An inexperienced Product Manager will say, yes, I do that always (as if that is a no brainer). An experienced Product Manager, on the other hand says, it depends on whether this customer’s requirements align with the Product vision. Sometimes, it is ok to say no to high-value customers, if the requirements do not align with the Product or Company’s vision. Got it ? A brief example but I am sure you got the point.
Use proper Product terminology: “You have to learn the rules of the game. And then you have to play better than anyone else.” – Albert Einstein. If you cannot speak the rules of the game, in this case the Product terminology, then are far from getting picked up. It is essential that you learn and are very comfortable with all the keywords for the type of Product role you are applying for. Examples of Product terminology related to Product interviews are – addressable market, Product support, Pricing lists, functional requirements, stakeholders. You have to sound smooth while using these and you have to know when to use what keywords. The keywords vary from role to role and you should check the job description of the job you are applying to.
Give examples: Often times, it is hard for an interviewer to fully understand the context of your answers. While you are speaking, the interviewer is trying to make sense of what you are saying. So it is recommended that during the interview, you insert examples from your own experience while answering the asked question. Experienced candidates do this spontaneously. For ex. you can say that “in this product, that I have worked during my time in company X, we performed A/B testing in this way, and we found out that…”
Ask Questions: This can make or break your interview. Product interviews often contain open ended questions like “how would introduce Product X in a new market in Latin America” ? Instead of getting started with your answer, a better approach is to step back and try to ask questions. Examples of this are – Are we talking about only Go-to-Market strategy or also determining the market need ? Do we have a product ready at this time or are you also referring to product readiness as a part of introducing it in Latin America ? Answers to such questions help determine the scope of your response and they will also let the interviewer know that you have the ability to think critically.
Once you determine your challenging area(s) from the list above, it is important to get help and address the area(s). Also, it is important to highlight aspects of the Product role that have you experienced in your previous role, even when you were formally not in a Product role. All of this needs efforts and more importantly guidance. Remember, if you need help, we offer a Product Bootcamp !
Good luck with your interviews !
Is your Product leaving money on the table? The answer depends on “who” is driving your product.
If Engineers are driving your product, it becomes a highly customized product. Services companies are born out of this approach. This gets the lowest profit margins for your products.
If Architects are driving your product, it becomes a highly configurable product. Many enterprise-focussed companies are operating this way. This results in lower profit margin for your products.
If Product Managers are driving your product, then this will maximize the profits for you, as most of the intended functionality will be available out-of-the-box.
As an analogy, think about the CRM application and how it has evolved.
Traditionally, organizations were getting this built for themselves. As a result, many services companies flourished building this for their clients. A little later, Oracle/SAP started building these applications. These applications contained a lot of modules, that had to be integrated during deployment. Needless to say, this was driven by Architects at these companies. As a result, this deployment was complex and needed a lot of manpower, eating the profit margins for these companies in these products. Later on, Salesforce came into the market with a product-driven approach. Look at where it has gone with its out-of-the-box product capabilities.
Examples of this sort abound in every company. We just need to look carefully to understand.
How to identify who is driving your Product?
When the requirements of the Product are discussed, observe who leads the requirements related discussion. Is it your Product Manager, the Architect or the lead Engineer who has the final say? Who is the final go-to person in case there are conflicts between these three critical team members on how certain functionality is to be implemented?
I have personally seen cases, where the Product Manager (PdM) was not confident about certain things in the newer architecture (a cloud-native architecture) and deferred the decision to the Architect. Ideally, the PdM should have taken ownership and performed the research to guide the team and the product.
Can a driver change in the course of product development?
It does not take long for change to happen, even when the Product manager might be leading it today. Reasons may include a newer technology (like the example above) or changes in the Product Management team. The new Product Manager may rely on the expertise of the existing team and leverage it more without intending to do so.
What is the remedy?
The Management team is the key here. The Software Development Manager and the Manager of the Product Management team are the ones to have a handshake about who will drive the Product. Any exceptions that happen should be pointed out quickly to these two stakeholders. Any changes in any of these teams (ex. Development lead, Architect, Product Manager or Product Owner) should be carefully planned and a close watch should be kept on how the team is dealing within, to ensure that the right person (the Product Manager) is driving the product.
Who is driving your Product? Are you able to spot the changes happening? And more importantly, how much is it costing your company?
Rick was the CEO of a startup. His company had a very promising product. He was selling to enterprises (B2B product) for which he needed every helping hand he could get. In November of 2015, he got an opportunity to be an OEM (Original Equipment Manufacturer) for a much larger company (Company A). He was very excited at the prospect. After all, this prospect would bring him additional 40,000 sales people from the new company, and had all the global customers he would not have been able to reach on his own.
But this also meant ensuing troubles that cost him a lot of time/money/resources. Was it worth it, you may ask ? Troubles started right on Day 1:
- Building a business case : It took him several meetings and a few months of scheduling/re-scheduling to accommodate calendars of the people (Product Managers, Directors) at company A. Once they approved of the product, a business case needed to be built for General Manager and other executives of company A. Not only he had to submit the technical/marketing collateral to build such a case but had to support the entire team by answering questions around business, market, customers, legal, technical support, competition whenever he was asked for it. A lot of work as a pre-requisite to the actual OEM !
- Margins, Profits, and SKUs: He had to compromise at a 70-30 share. Of any deal Company A would keep 70% and he would get only 30% of the deal. Still, a good deal, he thought. But when he worked out the numbers, he would not make much unless they did around 8 deals (with some combination of small, medium and large-sized deals) per year together. Company A had a 2-month long SKU creation process. That means, he had to wait for 2-months just for his product was available in the ordering catalog of company A. Not a big deal he thought, as he was planning to use this time to get some deals.
- Selling, selling and selling: Over the next few months, many prospects came. Whenever they came, Rick’s team was asked to chip in for every meeting explaining the product, traveling to customers’ site for joint presentations, filling in RFPs/RFQs, submit new collateral as needed, develop additional use cases and related collateral. The demands from company A were endless. The prospects stood tall and were progressing step-by-step in the sales funnel, but none of them converted for months.
- And a win after all! : Finally after 18 months of the processes and selling spiral, he got a win. The winning deal had his product with another company’s product, product revenues split 50-50 between them and Rick ended with a mere $1.2 million for the deal.
By this time he had 70% of his team working for this company, he had lost focus on other customers, his sales people had churned out, he had almost run out of money, most of his development and support staff was supporting the only customer that came from Company A. It was also harder to pull out of this deal due to the legal complexities.
Would Rick have done better on his own, without going in as OEM ?
What are your thoughts ?
A few months ago, one of our proposals got rejected because of our pricing. It was on the higher side for this client that was based in Asia. We had proposed a lump-sum payment (aka as perpetual pricing in the Product Management lingo!) for our product license.
The client did not have much room in it’s budget in this year and the next. Our proposal definitely offered a good ROI (Return on Investment) for the customer. But because of their limited budget, the client found our pricing very high.
Upon further probing we found out that the client was keen to consider this as OpEx (Operating Expense). As you may know, the operating expense is the monthly/annual expense that consists of items like salaries, internet and other routine expenses. On the other hand, CapEx or capital expenditure carries a big price tag upfront and with one-time payment. The CapEx typically include assets like computers, furniture, real-estate etc.
Now after our proposal was rejected, we started working on revising it to take it back to the customer. The silver lining here was that client had liked our product. We just needed to work within the client’s budget. Besides this, we also knew that the client was open to Opex pricing.
Here is what we did. Have a look at the following chart. The overall price is around $1.2 million dollars. In the first proposal, the entire amount is being charged upfront and the customer gets to use the product for its lifetime. In the second chart, we split the entire amount into multi-year payments so that the customer starts with a much smaller investment. This is the subscription or the pay-as-you-go pricing as the customer is paying as they go on using our product.
|Software License Price (Total)||$1,240,000||$0||$0||$0|
Table 1 : Perpetual or One-time Pricing
|Software License Price (Total)||$310,000||$310,000||$310,000||$310,000|
Table 2 : Subscription or Pay-as-you-go Pricing
- Revenue Recognition: The revenue recognition from subscription pricing happens periodically. So if the deal is for two years, then only 1/24th portion of the overall revenue gets recognized every month. This is the hardest part of offering a subscription pricing on your product. You and your management need to be comfortable with recognizing only a part of the entire revenue throughout the subscription period.
- SKUs/Part numbers for subscription: Your ordering tools need to reflect the subscription pricing. The older SKUs/Part numbers will not work with the new subscription pricing. Subscription pricing should reflect the product ID and the period of the subscription. For example, if Apple is offering a two year subscription on its iCloud, the SKU should be along the lines of “iCloud – 2YR”. Without this clear demarcation, a lot of confusion can happen when other teams like operations and finance (that are working closely with you) are pulled into the approval/sales process. Also at larger companies, getting these support teams (Finance/Operations) to release the subscription SKUs is a big challenge for a Product Manager, if the organization has been only offering perpetual SKUs till now.
- Technical Support: One of the smartest ways to limit the usage of your product beyond the subscription, is to offer product support for the duration of the subscription. For this reason, the subscription SKUs come in handy as they help the support team to quickly validate whether the support should still be offered. Once the subscription period is over, then you can cut back on the product support so that customers will not be able to get technical support, upgrades or updates on their product.
So as you can see apart from the lower entry point, subscription pricing also offers other benefits. But as a product manager you need to understand that it brings its own complexities and processes that you need to be aware of.