Tag Archives: product management

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

Moving from Free to Paid: 3 things that you cannot afford to mess

Often consumer online products need a critical mass of users to even know if the product is indeed 6280507539_f32a72be10_qworking and adds value to the users. Most products start by offering the product/service free to attain critical mass and also get actively engaged users. No sooner does it gather enough engaged users, the juggernaut of “monetization” is on its way and the only model that might be feasible is the user-paid model. Most products usually have a well-thought road-map on how long the free model must continue and how to start some positive cash flow. When you move to a paid model, you could mess up totally by doing these:

Convolute the user experience: This strategy only spells doom for the product. Alternatively, look at features you can carve out for paid users; the user experience of the product as a whole should be left in-tact. Sometimes it so happens that the whole set of existing features forms the perfect user experience and removal of any feature cripples the product so much so that it becomes useless. In such cases, the challenge would be to create new feature set – which are enticing enough for a segment of users to pay or create a limited time period for usage of the free product.

– Delay moving away from free: The conversion percentage from paid to free is usually a small fraction; running free version for a long period increases the cost of acquisition of paid users.

– Asking for “long-term” commitment: Users moving from free to paid should have a smooth “on-boarding” experience. Mandatory long period sign-ups (even if there is opt-out facility) causes high drop-out rates among users.

You build your user base with a lot of effort – let it not wither away when you need them the most.

 

Photo credit: https://www.flickr.com/people/68751915@N05/

Solving the puzzle – “water proof umbrella”

In my previous post, “Case Study: The Waterproof Umbrella” I wrote about “Out of Context engineers”. Engineers who are working on product or on feature but are not sure about its usage or need. While the earlier post was focused more on challenges, this time it is more about what a product manager should do to help engineers gain contextual knowledge.

There are ways by which you as a product owner can make the out-of-context engineers have a better understanding about product.

Detail requirements along with context : Charity begins at home, so why not start with little extra effort to help engineers understand something more about the product needs. When you write requirement definition or user stories, do ensure to include sections like “feature purpose”, “problem definition”,  “Expectation (from feature on implementation)”. A typical ‘User Story’ with ‘uses cases’ is not good enough for many engineers to understand the context or need, it rather just focuses on solution space and has bare minimal focus on problem definition or customer voice. Including suggested section along with accurate data helps engineers to connect problem definition with use cases and in-turn helps in designing an effective and elegant solution.

Customer experience : It is highly recommended that engineers who mostly have cubicle working habits should be taken out to meet customers, partners and field staff. When you go out to meet customers for a presentation or for a follow-up meeting, take one of these champs along with you. Let them have customer exposure, understand the expectation from horse’s mouth and feel the context. What is being suggested here is not something new but is definitely something which is not practiced so popularly; successful product companies like Intuit does practice this which is termed as “Follow Me Home”. You will also find a reference of this in “Lean Start-up” by Eric Ries. What this does is that it brings in a lot of contextual information to engineers, helps them understand that the customer focus is more on solving a problem and not necessary developing a feature as mostly perceived by engineers.

On many occasions, there are business or legal constraints due to which it is not possible to take an engineer along with you. For such scenarios, ensure that you share experience from customer meeting with the team and help team come to same level of understanding as you are.

Market updates : Send out updates in form of write-ups, ppts or even as a small talk once in a while to engineering team on what’s happening in market place, what is competition doing, newer announcements by government or by compliance agencies which could probably impact a feature or aspect of your product design. You chose the frequency, but ensure do not over-do or be so rare that engineers lose interest in such updates. This is an attempt to keep engineers connected with market place and also help them understand the business aspects of the product. They will sooner or later appreciate such information and also its implication on feature design or product road-map.

It is always advisable to have someone in the team who can challenge your understanding, only to help develop a better product and a better professional out of you. I take this as part of product manager’s responsibility to keep his team connected with the market and in turn with customer. Spend some extra time to detail out things that you might not have been doing, spend some time educating your team to ramp-up their understanding about business and problem you are trying to solve.

@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))

5 things that Scott Cook looks in a Product Manager

The Power of Product Experiments - insights from Scott Cook, Intuit Founder

Scott Cook in the session

23rd October, 2013 will be a date I will remember for a long time to come. I was among lucky few to be invited by Intuit Bangalore to participate in “The Power of Product Experiments – insights” session conducted by none other than Scott Cook, the founder of Intuit.

While there was tons of learning and insights shared by the champion on product experiment, there was something in particular for product management professionals that I wish to share with you all. Answering to one of the questions from audience on “What traits does he look in a product manager?”, he said:

  1. Passion
  2. Problem solver
  3. Learner (absorb all like sponge)
  4. Someone who gets things done
  5. Subject Matter Expert on something and is willing to learn more

cross posted on : http://successmanagers.blogspot.in/

@mathurabhay

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