Unfortunately, some customers may not always be happy with your company’s product or service. As long as the majority of your customers are happy with it, most of the time – you are probably doing fine. However, every once in a while you may encounter a customer that is more than just “unhappy”. In fact, they may even be furious. Any situation where a customer is grossly unhappy with your solution, and possibly experiencing negative financial impact or a major loss of productivity, should be defined a “customer crisis”. Read the rest of this entry »
Archives for posts with tag: product management
Whitepaper are often regarded as “sales tools”, created after product development is complete and as part of getting ready for sales. But a whitepaper can do much more than augmenting the company’s sales collateral. It can help crystalize the product strategy and establish the value of developing a specific product or a service in the first place. After all, a product should address a specific customer need and deliver economic value – and that’s precisely what a whitepaper is supposed to communicate. 
I started working as a product manager for a company that focused on developing electronic system-level (ESL) design tools. Without diving too much into the technical minutia, ESL software tools help engineers quickly model a complex system and simulate its behavior – without spending a ton of hours on its specific implementation details. Think of it as helping architects quickly sketch and visualize a large building before diving into the details of each and every part of its structure. ESL tools let engineers “play” with different concepts for a large electronic system, pick the best concept, and only then proceed through the arduous process of actually designing and building it.
The product I was hired to manage was supposed to provide a link between the ESL tool the company offered, and 3rd party hardware design tools that already existed in the market. I was very excited about the prospects of such a product, but for a while it seemed like I was the only one…
A couple of weeks after I joined the company, the engineering manager responsible for developing the product quit the company, taking half of our small development team with him. The remaining engineers on the team looked quite demotivated themselves, and I am pretty sure started looking elsewhere for a job.
It was hard to garner support for the project throughout the company. The project was generally viewed as an “interface” between our “high level” design tool and 3rd party “low level” design tools. And when engineers face the choice between enhancing and improving “our tool” vs. creating an interface to “other tools” – their preference is quite clear…
I could tell by the looks of other folks in the company that they thought my product was clearly doomed, and my days in the company were numbered. However the phrase that kept running through my mind at the time was: “It ain’t over till it’s over”.
I decided to write a whitepaper titled: “Bridging the Gap between Concept and Implementation”. It described the overall process of designing a complex electronic system – starting with the conceptual level, where key architectural choices are made, all the way through the detailed design level, where actual hardware is designed. It further described the need to develop an adequate testing framework that would ensure that both the high level model and the detailed implementation meet the desired functionality.
My whitepaper highlighted the gap that existed between our ESL tool and the other hardware design tools. The engineers who worked on the system architecture used our tool to capture the system functionality. Once their task was done, they “tossed it over the wall” to the hardware designers, who had to essentially start from scratch in a different design tool. The gap between the high level and the detailed design phases made the overall process significantly longer and much more error prone. However with the help of a “little interface” between the two types of design tools, we could dramatically reduce the overall design time, improve the final product quality, and save our customers a ton of money.
The value to the customer which was described in the whitepaper was quite straightforward. But it also pointed out the business benefits to our company. Given an interface to hardware design tools, our ESL product would get into the hands of many more hardware engineers, which meant growing the number of seats we sell, and increasing the value of each seat.
The project, officially named the “Hardware Design System”, eventually gained full management support. It became easier to recruit engineers to work on it, and our sales teams loved the prospects of making extra $$$. Once launched, the product exceeded all expectations and became one of the company’s main revenue sources. Not too bad for a “half dead product”…
I don’t want it to sound as if the whitepaper did all the “magic” by itself. It still took multiple internal meetings and heated discussions to get the message across and win support for the project. But I would say that the whitepaper laid the foundations for the whole internal campaign.
The same whitepaper, with a few modifications to fit it for external use, became the cornerstone of our outbound marketing campaign. It established the key messages, which were later used for developing all other sales collateral – presentations, datasheets, etc.
Granted, not every product development is driven by a whitepaper. But the basic tenants of ‘customer problem’, ‘alternative solutions’, ‘our solution’ and ‘why it’s better’ should be captured in every solid product requirement document (PRD). And once captured correctly, then creating a customer facing whitepaper should be mostly a “cut & paste” operation.
What does politics have to do with product management? Actually, a lot! I realize that most people view “office politics” as a negative activity that involves shameless manipulation and occasional back stabbing. I shared similar views of office politics myself. But that changed after I attended a presentation at the Silicon Valley Product Management Association (www.spvpma.org).
When the presenter got on stage, his first question to the audience was: “who amongst you likes office politics?” Hardly anyone raised their hand. He then asked the opposite question: “who amongst you dislikes office politics?” And the whole room was filled with hands in the air.
“Well, I’ve got news for you” said the speaker, “wherever there are two or more people – there’s politics”. He paused for us to absorb the news, and added: “Your only real choice is either to participate in the political process or to become a victim of it”. This was a moment of epiphany, and not just for me. I realized the speaker was right.
But wait, I am not suggesting that as a product manager you should engage in negative practices, start manipulating others, or back stab colleagues – just to promote yourself. I do however suggest that you become aware of the political processes around you, get familiar with the “rules of the game”, study the political power landscape and plan your moves accordingly.
Let’s take an example: suppose you realized that the product you’re responsible for needs a new feature urgently. Your key competitor just introduced a similar feature, and your customers give you clear indications that without this capability, your company will likely lose against its competition. The engineering team is hard at work implementing the set of requirements you’ve all previously agreed to, and the release date is quickly approaching. What do you do?
One option is to step into your weekly project team meeting and announce that the release plan must be changed to accommodate the new critical feature. Most likely, all hell will break loose as soon as you make this announcement. Fierce arguments will ensue, and chances of arriving at a decision to change the release plan are slim.
The other option is to assess who the key stake holders are, and devise a plan to get them on your side – before the critical project meeting. Let’s assume that your engineering manager is one of those stake holders. Sure, he is committed to the success of the product, but he is personally held accountable against key performance indicators (KPIs) such as delivering releases on schedule, within budget and of high quality. Changing the release plan will likely to impact some or even all these KPIs. In your discussion with the engineering manager, you reiterate the business motivation, but you also acknowledge the potential impact to the KPIs. You may propose to personally present to upper management the new market drivers for the release plan change, and ask for “readjustment” of the aforementioned KPIs. This one-on-one conversation is likely to put the engineering manager on your side. And when the subject of modifying the release plan is brought up in the project team meeting, you will have a strong supporter to back you up.
This was a fairly simple example. In reality, the political scene is often more complex, and so are the motivations of people involved. You could start feeling your way around by answering the following questions:
– Who are the key stake holders whose support I need to gain?
– What are their organizational objectives?
– What are their personal objectives?
– What objections might they have to my proposal?
– What can they potentially gain from supporting my proposal?
Once you have mapped your key “targets”, schedule one-on-one session with each one. Come prepared with the background work you’ve done, and do your best to convince them to support you. Be fully prepared to listen, as you may uncover motivations and objectives quite different from what you envisioned. Where needed, negotiate a “win-win” agreement that addresses both their objectives and yours.
Granted, not all scenarios can be planned ahead. You are likely to run into situations or meetings where the political dynamics happen in real time. As you become more proficient in the “political process”, you will be able to handle the dynamics as they unfold. Don’t just wait for the next political conflict – spend time regularly with other stake holders, understand their motivations and invest in building rapport. The more you do it, the more you succeed in steering decisions your way.
As a product manager you simply cannot afford becoming a “victim” of office politics. Your ability to influence key product decisions depends on how politically savvy you are. So rather than trying to “avoid” office politics, make it part of the skills you acquire. There are plenty of books and websites that offer advice on office politics. Take the time to read about the subject, pick those tips that resonate with you, and start practicing…
Developing, manufacturing, promoting, selling and supporting a product involve multiple departments within a company. A typical division of responsibilities may look as follows: The engineering department designs and develops the product – be it a hardware device, a piece of software, or a service. Manufacturing is responsible for building products in quantities to meet demand. The marketing department promotes the product using vehicles such as public relations, advertising, tradeshows, etc. The sales department is responsible for selling the product to potential customers. And finally the technical support department resolves any problems customers encounter while using the product.
With multiple departments involved in each product life cycle, coordination and alignment become critical to product success. Orchestrating the activities of all the departments involved is the primary responsibility of a product manager. In many respects, the product manager is the ‘Chief Executive Officer’ (CEO) of the product.
The challenge that every product manager faces, is that unlike a CEO, the various departments involved in the product lifecycle do not report to him. A product manager is rarely in a position to “order” a manufacturing manager, or an engineering manager to do the right thing for the product. The secret to a product manager success is the ability to convince the various departments to march in the same direction and effectively collaborate to ensure product success.
The product manager primary job, and a key to his /her success, is to build a leadership position; a status that will grant them authority over the various departments. The process of building product leadership requires the use of political skills – in a positive sense. It certainly helps if upper management provides the right backing for the product management team. But at the end of the day, it is the product manager who must handle the daily challenge of maintaining his/her product leadership status.
Assuming job #1 has been accomplished and the product manager has leadership/influence over the other departments, his responsibilities should include the following:
- Product requirements: identify the key customer requirements engineering should implement in a new product, or subsequent releases of an existing product.
- Feature prioritization: reach agreement with engineering on the priority and implementation order of features, and the actual content of a product release.
- Release planning: plan a schedule of future releases that introduce new features and necessary fixes.
- Pricing: of the various product offerings, options and related services.
- Messaging: define the key messages and the product positioning. Work with the marketing department to deliver those to customers and partners.
- Competitive positioning: analyze competing products/services in the market and define key advantages to be highlighted during the sales process.
- Sales enablement: create educational materials and train the sales force on how to best position and sell the product/service.
- Deal support: provide any required assistance to sales people; personally engage to help win strategic deals.
- Crisis intervention: become involved with, and help resolve major breakdowns that occur at strategic customer deployments.
Product management is one of the most complex and challenging positions within the organization. As the saying goes – “Success has many fathers, while failure is an orphan”. When a product succeeds in the market place, engineering takes credit for building a great product, and sales will pride themselves on their ability to drum-up customers. But when a product fails, the product manager may find himself carrying the blame: feature requirements weren’t clear, or incorrectly prioritized; messaging was murky; sales were never properly trained; etc. So why should anyone wish to hold such a position?
If you love to drive a team, build consensus and watch it succeed in creating something new. If you like to deal with multiple disciplines, and interact with all parts of the organization. If you love engaging with customers and keeping your fingers on the industry pulse. If you want to exercise your analytical skills, communication skills, and people skills – then you will find the role of a product manager ideal for you. And if you dream of becoming a CEO of a company, there is no better training than a product manager job.
The Art & Science of Product Management 