Category Archives: Leadership

Jeff Lash @ ‘The Three Questions for Product Manager’

Jeff-Lash

Twitter: @jefflash

Jeff Lash is a product management adviser, researcher and a blogger. He is the Service Director of the Product Management advisory service at SiriusDecisions, the leading global b-to-b research and advisory firm. Jeff plays vibraphone along with several other instruments. We thank Jeff for taking out time and be part of ‘Three Questions’ series for product managers.

Product Mantra: Is “data driven decision-making” killing the innovative thinking among product owners?

Jeff Lash: Quite the contrary – at SiriusDecisions, we still encounter product management teams that base a lot of their decision-making on anecdotes and gut instinct rather than objective data. Innovation and evidence-based decision-making aren’t in conflict – in fact, they work well together and in many cases you need them both.

For example, it’s okay to think about innovative ideas for new products or product enhancements. However, instead of just running off and building them, product managers should look to conduct concept testing to see whether these ideas have merit and, if they do, to help iterate and improve upon them. Similarly, data can be extremely helpful in identifying opportunities to innovate. Quantitative data – from a variety of sources, including everything from market overviews to web analytics – can help identify needs, pain points and trends, and that can inspire innovative ideas that wouldn’t have been identified otherwise.

It feels as though people take a position on either end of the spectrum. On the one side, there are people who quote (or, more likely, misquote) Steve Jobs or Henry Ford and believe that customers don’t know what they want and you should just come up with innovative ideas and try and move the market. On the other side, there are people who believe every question in life can be answered through an A/B test. The reality is that there is a happy medium in the middle.

Product Mantra: What are three things that you don’t want a product manager to spend his or her time on?

Jeff Lash:

  • User experience design. This is a topic that is coming up more often, especially for SaaS products, as the lines between product management and user experience are sometimes unclear. Product managers certainly should care about user experience and work closely with UX practitioners. However, if they’re getting into the details of design, that’s a problem, since often they don’t have the skills or experience to do good UX work, and it means that’s taking time away from other important activities they should be doing. I wrote more about this in my blog post Product Management is Not User Experience.
  • Detailed specifications. It’s very easy for product managers to slip into specifying the details of how a capability can be implemented. For those product managers who were former developers or engineers especially, they often know the product or the underlying technology so well they could specify how it should be built. That’s not the job of the product manager, though. And in Agile, even though functional specifications aren’t produced as a formal deliverable, the same sort of detail is being created for each story – often in the form of detailed acceptance criteria. There are plenty of other roles that can handle the specifications – and often do a much better job – but there’s only one product manager. When product managers can provide guidance and context to those doing the detailed work, not only are they themselves not spending time on those sort of tactical elements, but the end result will also likely be much better as well.
  • Anything for just one customer. One fundamental difference between product management and bespoke product development is that product management is focused on creating a product that can sell to multiple customers in a market or segment. Especially in startups, situations where one customer represents a large percentage of the revenue, or even when one customer represents a large percentage of the total addressable market, product managers can get drawn in to focusing on just fulfilling requests from specific customers. Product managers should listen to customers and understand what they want and why, but rather than simply following orders, they need to evaluate whether the feature or capability or change would be valuable to the target market as a whole.

Product Mantra: What traits should one look for in a candidate while hiring for a product manager position in a b-to-b market?

Jeff Lash: I like that you specifically asked about traits rather than skills or experience. Clearly, having a certain set of experience is important, but things like competencies can be developed in an individual, while traits are harder to learn or adapt. There are a number of traits that I think are important, but here are four I’d suggest looking for:

  • Passion. Product managers need to be passionate about the role and the subject matter in which he or she is working. You need passion to build great products, and you need passion to inspire others to build great products. Ask candidates what gets them out of bed in the morning and try to determine their level of passion for the role and the industry/customers/product.
  • Empathy. Product managers need to be able to empathize with buyers and customers and users in order to fulfill their needs and empathize with colleagues to create effective and high-performing teams. Ask candidates to tell an example of when they empathized with a customer or colleague and what they learned from it.
  • Humility. Humility will help product managers empathize with customers and enable them to relate better to your internal colleagues. It also enforces the idea of being part of a team – arrogance is a difficult trait to make work in a collaborative environment. Ask about successes and listen to whether the candidate only talks about his or her own role or gives credit to the others who contributed.
  • Tenacity. There will be challenges along the way, whether it’s trying to get management to fund a new product, resolving some technical issues or taking on a major competitor. People who have a low tolerance for overcoming challenges will struggle in the role. Ask about a time when the candidate faced an obstacle that seemed insurmountable and how he or she overcame it.

Thanks Jeff.

Jeff Lash on Social Media

  1. Follow Jeff on Twitter at @jefflash.
  2. Blog about product management at How To Be A Good Product Manager 
  3. Official blog post on the SiriusDecisions blog,

About SiriusDecisions
SiriusDecisions, the leading global b-to-b research and advisory firm. SiriusDecisions empowers the world’s leading marketing, product and sales leaders to make better decisions, execute with precision and accelerate growth.

@mathurabhay

Advertisements

Rich Mironov @ ‘The Three Questions for Product Manager’

Rich RichMironovMironov needs no introduction. He is veteran in product management and has provided full-time and short-term product management consulting to more than 75 tech companies. We thank Rich for taking out time from his busy schedule to be part of ‘Three Question’ series for product managers.

Product Mantra: Which experience is more valuable for a product manager, sales, marketing or engineering? This considering that most professionals make their way into product management from one of these three functional roles.

Rich Mironov: Product managers need a balance of experience. For PMs who were previously developers/technologists, their engineering backgrounds are already solid. But They typically have little marketing/sales experience. They need to shore that up by sitting in on sales calls, digging into lead gen statistics, scouting competitor products, working out customer ROI models, trying (and failing) as a copywriter, listening in on tech support calls, etc. An ex-developer’s most likely failure mode is to assume that customers care about the finer details of features and interface, and that the buying process is rational.

Likewise, ex-marketers already understand messaging and channels, but will need a lot of technical street cred to work successfully with development teams. They should learn about software architecture, code-and-test processes, technical debt, and how much harder it to BUILD stuff than TALK ABOUT building stuff. An ex-marketer’s likely failure mode is wildly underestimating the effort to add (even small!) features, and to make customer commitments without agreement from development.

Etc. None of us comes to product management with a balanced experience base. We have to get out of our individual comfort zones to fill in the gaps.

Product Mantra: Thousands of products are being developed worldwide every year. Unfortunately most of them fail in their purpose. What are three most common blunders committed by product managers in early stage of the product development?

Rich Mironov: IMO, most products fail because their target buyers aren’t sufficiently interesting in the new product. We talk ourselves into believing that prospects are much more excited than our objective evidence indicates. Three common forms of this overall blunder:

  • Willingness to build just what we’re told to build, as described by executives or salespeople or developers. Over and over, I see products in development that “our CEO said that people wanted,” or that make sense on paper, or that only one customer demanded. Every product manager should gather first-hand input from a few dozen potential buyers in the actual target segment – and confirm that the specific product has a paying audience. (As Steve Blank says, “Get the heck out of the building.”) Our job is to validate other people’s seemingly good ideas.
  • Not having a back-of-napkin revenue model: vaguely how many units do we need to sell in the first couple of years, at what price, to justify our expensive development team? Does Sales or Marketing agree that these projections are reasonable? Has any player in this market ever achieved similar sales results? Too often, I see companies spend $M’s in development without running the basic financials.
  • Assuming that product management is the best source of good ideas. Our job is to make sure that good products are build and good decisions are made, not to be the smartest folks in the room. Some terrific ideas (and a lot of bone-headed ones) come from developers, from channel partners, from customer suggestion boxes, from executives, from competitors, from analysts. We need to filter the incoming stream, discard the obviously useless 95%, and have the best thinkers in our organization give the interesting 5% a thoughtful review. And then validate-validate-validate the proposed mix of features/fixes/new products. We leave our egos at the door.

I see fewer products fail because development is hard (which it is) or because most releases are late (which they are). No matter how great our engineering teams are, they can’t save us from mediocre or stupid product plans. So the most wasteful thing we can do is excellently build a market-failing product.

Product Mantra: How soon should a start-up hire a product manager or for how long a founder(s) should continue playing the role of a product manager.

Rich Mironov: I usually recommend that a start-up hire its first professional full-time product manager when it hits 12-20 people.   That’s when the informal communication overhead of a 6-person company (everyone sitting around one table) breaks down, and everyone is suddenly having trouble staying current on customer commitments, priority priorities and development capacity. Someone (a product manager) has to provide just enough process so that the development team can stay productive. See a recent 45-minute talk of mine on this: http://www.mironov.com/startuppm/ .

This can be a very touchy discussion, since founders SAY they want to give up day-to-day control over product details, but rarely ACT that way.   They’ve been making every single feature/UI/architecture decision early on, as the company sailed past a series of potential disasters, and that worked well when things were small. Changing their management style and operating model is VERY difficult. Newly arrived product managers at small start-ups have to earn the trust of the founders by handling increasingly important decisions in full view – so that founders can slowly relax their grip on every button placement and color choice.

About Rich Mironov: Rich coaches product executives, product management teams and agile development organizations. He is a seasoned tech executive and serial entrepreneur: the “product guy” at six start-ups including as CEO and VP Products/Marketing. Read more.

@mathurabhay

Product Management by Committee

One of the key issues that plagues a delivery team is having no Product Manager to guide the team. However, something that is more troublesome is having multiple Product Managers for a single product. This is what is sometimes referred to as “Product Management by Committee”. I am reminded of a scenario where a boat in a race had 5 people managing it and 4 people actually rowing.

Did you say “Oh, Come on..!! it can’t be that bad” ?

I personally feel that if you want to set a team up for failure, this is one of the things that you could definitely do.

Let us take a closer look at what the problems could be, with having multiple product managers.

Same goal, different priorities: Each PM tries to push his Agenda. Many times, each PM might have the same overall goal, but different priorities. They don’t want to contradict / confront each other. Often, they end up talking to some key resources in the team and pushing their items / enhancements without letting the other PMs know.

Collective knowledge or Collective confusion? There is a possibility that each PM has a different understanding to a scenario in the Product domain. For example, 2 PMs might have varying understanding of how an Insurance claim is to be handled when a car being driven by a person less than 25 years of age gets into an accident at a roundabout with a car driven by a drunk person. In such a scenario, the team would be chasing a moving target if they have to listen to both PMs.

Personality clash: PMs come in all shapes and sizes. Some are more technically oriented than others, some more forceful, some more knowledgeable and some more articulative. When you have a mix of such people providing directions, the team would be torn apart and staring straight at failure.

remix-monkeys-dance-clan-by-same-cc-by-sa-3-0

When Ted, my colleague took up the role of the Scrum Master for one such Agile team, this was one of the things that he identified as a failure factor. He set up a meeting with all 4 Product Managers and told them that henceforth the team would be happy to take inputs from all of them, however, all decisions and directions only from one of them. The PM committee now had to decide who that would be. They nominated Dave ( one of the key stakeholders within the PM committee) to be that person for the duration of the current release. This meant that

  • Dave would set priorities for the team and define the Acceptance criteria for each story.
  • Dave would resolve any conflict of ideas within the PM committee and provide direction to the Delivery team.
  • The Delivery team is not faced with various personalities with different agendas providing conflicting requirements. The team and PM have an opportunity to understand each other well and compliment each other for a successful delivery.

The team is now slowly increasing their iteration velocity, meeting most iteration commitments, gaining the trust of senior management and is able to enjoy their work. I believe this change has been the major factor in causing this turnaround.

Let us know what you think…

@SampathPrahalad

(Pic: Thanks to Remix Monkeys (A new creative look and Style on Urban Dance))

When the Product Manager is no longer really a Product Manager

When a new game changing feature is introduced, a Product Manager Owner – true to one’s role, does not draw lines limiting responsibilities, owns all the aspects of the feature from operations to user experience to go-to-market. The Owner comes up with the metrics that needs to be measured, works closely with all the departments like the master of an orchestra to ensure that the feature delights the customer and meets business objectives. This will usually take several iterations, pivots based on learning from experiments and sometimes operational changes for the product to gather critical mass and reach a cruising altitude. What happens next usually is that this Product Owner sub-consciously transitions into Product Manager – continuing to manage every nitty-gritty of the feature in a typical run-the-business sort of operation; nothing wrong – perfectly fine. This sub-conscious operation leads to most often playing the roles of Program Manager or an Engineering Manager or an Operations Manager. Organizations can often fail to take cognizance of such a situation and any such protracted scenario can lead to:

  • Professional staffing ignored: Product Manager operating in roles which require specialized skill-set to maximize efficiency can reduce overall efficiency. For example a skilled project manager brings his expertise in efficient resource utilization and a product manager really may not be able to concentrate on that aspect they way it should be done.
  • Reduced strategic thinking: The Product Manager is bogged down by issues that needs to be solved to run the business that he stops thinking strategically from a product’s road map perspective. A product stagnates. Crossing the chasm after a long period gets tougher and interventions become painful.
  • A rock-star Product Manager does not remain one

What should be done ideally?

  • A product manager (ideally the director of product management) should identify when the product’s/feature’s gestation period ends and requires product management not to hang-on to things which are not typically functions of product management. This requires structural changes in the organization and establishment of matrix structures to function effectively
  • The product manager should define process and the corresponding operational metrics required for healthy functioning of the feature and help in setting up specialized teams for the purpose before abdicating some roles which he used to play

Tailpiece

There is another school of thought that Product Managers have to be jack of all trades. Definitely, yes. It is needed during gestation period and perhaps during formative years of the product.

Prevent Product’s Mortality

There are situations when a product manager takes certain steps that are not so commonly expected from the owner of the product, like escalating issues to top executive. While many may consider this as weakness or inability to handle certain situation but at times in the interest of product it becomes important that the product manager escalates certain issues / situation to top executives. Two main reasons that I experienced that caused such a scenario are: “engineering fails to understand business priorities” and “business fails to understand engineering challenges”. And reasons for such a situation are;

  1. Out of sync engineering
  2. Pressure of numbers from business

Out of Sync engineering

Engineering has simply failed to appreciate the business needs. They are working at slower than the expected pace or in a different direction. Engineering must work at the right velocity – a combination of speed and direction; if not, they are sure to miss on certain critical milestones set by business. It only means that in such situations the organization is bound to miss on some of the opportunities and will have to take a hit on either top line or bottom line or both.

Along with speed it is also important that the Engineering works in the right direction. This means that there is no gap between what is expected and what is being developed. While a Product Manager is expected to take care of such deviations many a times the Product Manager becomes a helpless spectator of being overwritten by design limitations, technological challenges or simply by someone in higher up ranks in engineering who is not aligned with the product vision.

This is a situation that I call as ‘out-of-sync’ – the Engineering is out of sync. The least that is expected out of a Product Manager at this stage is that he merely acts like a spectator and let Engineering go out of sync with market/business expectations. It is very much the duty of a Product Manager to ensure that he escalates such ‘out-of-sync’ situations to top executives at the right time for them to intervene and ensure that engineering is back in sync with the business priorities.

Pressure of Numbers from business

Profit is purpose of business and it is this purpose that drives all activities within the organization. When numbers are not met (top line or bottom line or both) the pressure of missing targets is sure to percolate down to all departments and projects.

When winning new orders becomes tough, when supporting legacy product eats up to much of bottom line and with customer satisfaction levels takes a nose dive, it is natural that pressure on new product being developed will be high; this is for a simple reason that everyone in the organization believes that the new product will ease their life and this new product is the only savior.

The probability that this pressure will break the team (Engineering team) is very high. Pressure of numbers has potential to crack and break a well settled voyage. And unless the Product Manager jumps in and escalates such situations to top executives, chances of a complete burn-out is very high; only a soothing balm from top brass will help reduce the pressure on Engineering.

Concluding remarks

While Product Managers own  a product and they are the one who decides on priorities, it would be wrong on the part of the organization to leave everything up to a Product Manager and enjoy the show. For Product Managers it is important to understand that they are the one who must initiate these escalations in the interest of the product and strategy. To win you must have a committed and passionate team and what could be better than to have top management also in your side.

@mathurabhay

Putting on your negotiation hat

IMG_0452

This post is dedicated to one of world’s best negotiators, Nelson Mandela. His negotiations with the South African apartheid government are a great example of a skilled negotiator.

Product managers perform a leadership role within a company, continuously performing various cross-functional initiatives between development, sales, marketing and customer service teams. Conflicts arise often as each team tries to achieve their objectives and one needs to be really skilled at dealing with the differences. It is important to realize that when negotiating, both the relationship with the stakeholders and the outcome of the discussion is very important. A good strategy to follow in these circumstances is the principled negotiation method that is described in the book ‘Getting to Yes’ (Fisher and Ury). Some key highlights of this method are:

  • Focus on interests and not positions
  • Invent options for mutual gain
  • Use objective criteria

Always Focus on interests and not positions
Interests are the needs, desires, concerns, and fears – these are the things one really cares about or wants. They often underlie people’s positions and this is the tangible item that people say that they want. As Fisher and Ury explain:

“Your position is something you have decided upon. Your interests are what caused you to so decide.”

An example of this would be negotiating on features for the next major release. After intense planning with various stakeholders, a product manager releases the plan for the next six months. An executive would like to add an additional feature; the conversation could go something like this:

Executive:  I would need this additional feature in our next release; it is for our most valued customer. It really needs to be in the next six months.
Product manager:  The current features in the roadmap will take six months; this has been carefully planned and estimated. We can consider removing one of the existing features and adding this one.
Executive: That is not possible, our clients are expecting these features, we have already committed to them.
Product manager: What is the reason you need this feature in the next release? Maybe I can suggest an alternative solution?
Executive: I promised our client this feature for the next release some time back, I need to keep to my word.
Product manager: This is interesting, I had a discussion with the same client recently and I am almost sure we can offer them an alternative solution. Maybe we should have a discussion with them and consider our options first.
Executive: Okay, let us go ahead with this discussion.

Note how the executive communicated his position first and his interests were revealed only after asking the ‘why’. Also notice how the possibilities become broader when his/her interests become clearer. Once the interest is revealed, various solutions can be considered.

Inventing options for mutual gain
It is important to generate not just one but many options when considering solutions. Way too often only one option is considered simply because stakeholders believe they know the right answer, and this leads to premature closure.

Product managers must take the lead to understand the problem space and assist in generating various options. He/she has deep product knowledge and also a good technical understanding; this is an advantage when generating creative solutions.

Brainstorming can be used to generate options and it is important to separate the act of inventing options to the act of judging. First invent, and then decide later.

“Expand the pie before dividing it – skills at inventing options is one of the most useful assets a negotiator can have.”

Insist on using objective criteria
Facts and data are really important in negotiation, it is important to seek  “a wise agreement as judged by any objective standard”. During negotiations, never yield to pressure, only to principles.

Executives and managers like to make very strong statements about products, this is great but always keep in mind, these are just opinions. Keep an open mind, invite them to state their reasoning, suggest object criteria and refuse to budget except on this basis. Product managers must drive decisions based on data, this could be: market and customer related data, product metrics, and technical information. At the same time be open to reason and be there to actively listen.

Does a PM know if a feature is over-engineered?

I often come across my Product Manager friends fretting about “over engineering” by their product development team. “Over engineering” leads to more time and money – which is a source of worry for the Product Manager. Does a Product Manager know if a feature is “over engineered” by engineering? Perhaps, Yes. Is the extent of engineering required for a product, a Product Manager’s prerogative? Perhaps, No. We love to state and perhaps over-state that Product Manager is also the complete owner of the product . Product Manager is of course the custodian of the business aspect of the product and has the say in what feature must go and the timeline of the feature. However, it is the engineering team consisting of software architects and developers who develop the product. Let us look at various scenarios based on two parameters: the scope of the product development and effort estimate. Continue reading