by Saeed Khan
While understanding things like “a day in the life” of your users can be very useful, most people have better things to do than recount the minutia of their job duties to you.
If you can’t get everything you need in one visit, try to get commitment for a follow up call or other conversation to gather additional information, but don’t push too hard if they aren’t open to it; you may alienate them.
Do you have any rules you want to share?
Tweet this: Rules for Customer Visits #2 – Moderation is key http://wp.me/pXBON-4aR #prodmgmt #research
By John Mansour
Unless your sales team is given quotas for each product, there’s no conceivable plan product managers can execute to meet revenue goals for their products. When they do meet their goals, it’s pure luck. There’s a better approach that doesn’t rely on luck and is more conducive to the success of the organization.
Why do organizations set revenue targets for each product? The theory makes perfect sense. If every product hits its revenue goal, the company will likely hit its revenue goal. But the execution couldn’t be further from reality. Sales people sell what they get paid to sell. All things being equal, they’ll sell what customers are asking for and look for opportunities to upsell or cross sell other products and services.
The Downside of Product-Centric Goals
So when product managers are given product revenue goals, there’s no possible way they can translate those goals into sales execution plans if sales goals aren’t product specific. The negative ripple effect just adds insult to injury.
It forces every product manager to lobby the sales force and convince them one product is more beneficial to sell over the others. It’s confusing to the sales force at best.
Imagine how it comes across to your prospective customers – selling what’s important to you instead of selling what’s important to them. It hurts the credibility of your organization.
The other part of establishing product revenue goals that makes even less sense is that no one is considering how your target customers view your organization. How would they position your organization to themselves in a way that offers maximum value relative to their goals?
Don’t Rely on Luck
B2B organizations that consistently meet their revenue targets don’t set revenue goals for each product. They set revenue goals for each target market segment so all product managers have the same incentive – to create product and service solutions that give sales people and the organization a distinct advantage in key market segments.
Benefits of Setting Market Goals Instead of Product Goals
There are a number of benefits to thinking about markets and market goals:
- Product planning priorities are much easier to establish because the primary focus in on removing the biggest obstacles your target customers are facing. Product priorities follow accordingly to create the solution.
- Marketing messages are more effective because they’re relevant to the industry and operational issues in each market segment.
- The sales force is pulled into more situations where you have a distinct advantage and your messaging speaks to decision makers, not users.
A market segment approach to setting sales goals doesn’t preclude the sales force from selling outside those segments. It just gives them more incentive to spend time selling to organizations in those market segments where you have an advantage.
Market segmentation makes it easier for your organization to meet its goals. Vertical marketing (by segment) and horizontal product management (cross-industry solutions) force product teams, marketing and sales to see your organization through the eyes of your target-customer organizations first. And when everyone is focused on helping those target customers meet their goals first and foremost, your goals are much easier to reach.
Tweet this: Meeting product goals is pure luck! #prodmgmt #prodmktg #sales http://wp.me/pXBON-48c
About the author
by Saeed Khan
First of all, thanks to Tina Turner for inspiration for the title of this post.
Second, this post is my response to the following tweet by Melissa Perri (@lissijean). I don’t know Melissa, and I have nothing against her in any way, so my post should simply be viewed as a response to the idea and not directed at her personally.
The manifesto itself - a work in progress – is structured in a form similar to the Agile Manifesto. e.g.
1. Focusing on customer problems over focusing on features
2. Problem exploration over gathering requirements
3. Small rapid experiments over large feature specs
4. Building roadmaps to reflect experiments and goals over building roadmaps to schedule work etc.
So first, mea culpa, I called it the “agile” manifesto, when it is actually the “lean” manifesto. Honest mistake, though you may be able to see why. So here’s why I’m not a fan.
What problem is it solving?
In a somewhat ironic reference to the first line of the manifesto, I wonder:
“Before listing out various statements, what problem is this manifesto looking to solve?”
I think this is critical to any definition process, particularly a collaborative one. Additionally, as Product Managers, shouldn’t this be the initial focus? A manifesto is a statement of intentions, motives or views.It is often a call for change to a situation or condition that has become problematic or untenable.
The US Declaration of Independence is one of the most famous manifestos ever published. Ironically, another very famous manifesto is the Communist Manifesto, written by Karl Marx and Friedrich Engels.
A more recent manifesto, the Peanut Butter Manifesto, was a call for change within Yahoo to address the malaise that one executive viewed as a core problem. What core problem needs to change for Product Management?
Why the focus on Lean?
This is the “Lean Product Management Manifesto”. Is this a manifesto for Lean Product Management, or is it a Lean Manifesto for Product Management?
I’m being a bit facetious here, but why not simply call it the Product Management Manifesto? I don’t want to assume I know Melissa’s intentions, but the word “Lean” is troublesome for me.
I’ve seen people put words like Lean, Agile and Extreme in front of “Product Management” to associate with some au courant methodology. When Agile was all the rage (it still may be though cracks are showing), and everyone was talking about “Agile Product Management”, I wrote a number of posts counter to the trend, including one entitled Product Management has always been Agile.
The point was that, development methodologies will come and go, but Product Management must rise above the product implementation process, both by definition and practicality.
As an aside — and again not asserting anything about Melissa’s intention — this recurring attempt to associate Product Management with specific development practices, e.g Lean, Agile etc., shows a lack of clarity on what Product Management is. It’s much broader than the Development process. It also possibly shows an inferiority complex. e.g. the Agilists are getting all the attention, so let’s associate and get some of that mojo!
Why the “me-too” format?
The format — <Action/Noun A> over <Action/Noun B> — is clearly borrowed from the Agile Manifesto. Perhaps this was the reason that I inadvertently tweeted it as the #agile #prodmgmt manifesto.
The Agile Manifesto is, if nothing else, a wonder of brevity. In very few words, it manages to define and propose a significant shift in how software projects would progress. The people behind the Agile Manifesto had a clear set of problems they were trying to address and chose a very clever and distinct format for their manifesto.
I like the Agile Manifesto as much (or more) for it’s form as for what it says, though the extreme brevity has caused problems as there is clearly a lot of context that is essential for understanding Agile that is completely ignored by many.
Borrowing the Agile Manifesto’s format for a Lean Product Management Manifesto has clear problems that will likely cause confusion. Why not apply some Product Management fundamentals to the Product Management Manifesto?
Say what needs to be said in a distinct format that is best suited to the problem at hand. This will help differentiate and position that manifesto as something that stands alone, and is not a derivative of something else, particularly a problematic software development manifesto.
We need discussion over declarations
Let me say that I see value in the discussion that Melissa has generated. There is a lot of confusion and misinformation about Product Management, even amongst Product Managers themselves. Check out this LinkedIn discussion — you may need to join the group. Over 350 VERY different responses to the question:
What exactly do you do here? What is your one line answer as a Product Manager?
Here’s one of the more unique responses.
“Translate ‘techno’ into ‘buzzo’ for the marketers and ‘buzzo’ into ‘techno’ for the engineers — someone has to do it!”
There were some other strange responses, and the sheer variety indicates there is significant room for improvement. If Product Managers can’t come up with some good definitions of what they do, how would anyone else?
High-tech product management is a VERY young profession; maybe 30 or so years old. I call Intuit’s founder Scott Cook the first true high-tech product manager. So there is a lot of work still to do.
Do we need another manifesto? No. But perhaps the discussion that Melissa has started will move things forward. It certainly inspired me to write this blog post.
P.S. Back in 2009, I also thought about defining a PM Manifesto, but decided not to pursue it after I thought through the problem and the best solution. The blog posts are still there for those who care to read what I wrote back then.
Tweet this: We don’t need another Manifesto #prodmgmt http://wp.me/pXBON-4a1
About the Author
Saeed Khan is a founder and Managing Editor of On Product Management, and has worked for the last 20 years in high-technology companies building and managing market leading products. He also speaks regularly at events on the topic of product management and product leadership. You can contact him via Twitter @saeedwkhan or via the Contact Us page on this blog.
by Mike Smart
A few years ago, a friend of mine recommended the book Topgrading by Brad Smart, Ph.D.
One “a-ha” moment for me was the cost of hiring and retaining a team member that doesn’t work out (or is retained for less than two years). The costs are staggering; $100,000 for every $10,000 of compensation.
I won’t bore you with the arithmetic as you can refer to the book, but I’ve found that proper onboarding results in a real payoff. Onboarding is the fair and equitable way to tell our product leaders and managers, “We want you to be successful.” It also identifies issues early and provides a path to correct them.
Onboarding should apply to everyone new to the company—individual contributors; managers and directors; even executives—and be tailored to past experiences and roles. An ongoing process with measureable results in a 100-day or less timeframe is best. This ensures your team, and most expensive assets, will always perform at their peak even when adding additional resources.
Why is this especially important for strategic roles such as product leader and management?
Not that long ago, I worked with a CEO of a mid-size enterprise software company that hired a product director. The director had industry experience, managed a team of product managers, and had an advanced degree from a prestigious school. He was a very “smart” guy. The CEO liked his education and intelligence—and was very behind schedule filling the role.
Some issues started to surface a few months after he accepted the role. He was “too busy” to check-in with his team, and didn’t request they spend time with customers to develop market knowledge—or do so himself. Two operations reviews later, a board member commented the product strategy lacked credibility and showing signs of decline.
Fast forward six quarters: The same board member asked with frustration, “How did we get here? The product strategy is a mess, our customers are unhappy and we haven’t delivered anything significant in almost two years.” He thought the product director was failing. The director had not created these issues but now he owned them.
An executive-level onboarding program would have helped the product director integrate the company’s goals, objectives and expectations into his job. Onboarding would have solidified what methods, resources and tools were available to him to accomplish key objectives. A formal process would have kept everyone updated on the progress and answered whether they had a great product leader and if he was a good, strategic fit. In fairness it would have given the director a tracking tool to let everyone know he was on course.
What does an effective onboarding program look like?
Here are six basic steps to create your own:
- Formally assess teams and individuals. Model your best practices after your current best talent. What skills do they exhibit?
- Create a scorecard. Define key results and outcomes for the team. Publish them!
- Create a complete feedback cycle. Talk to your organization—make sure all employees weigh-in. What do they want in the next 60-90 days? What was missing in the last 30? Do something meaningful and visible with the feedback.
- Promote and foster a formal and informal network. Set the stage and get out of the way. Let the informal network grow, but make suggestions on pairing-up team members as well.
- Focus on things that aren’t visible. Recognize individuals that embrace the role by practicing the skills and the process. Recognize and encourage a continuous learning environment.
- Keep it light, but fit. Make regular adjustments to the process to make it fit. This works best with a “just enough” process.
Successful onboarding is how some companies achieve the 10x:1 results the rest of us only dream about. It’s about leveraging your organization, increasing productivity and developing a successful product management team. I have seen it firsthand—this is a critical part of high performance teams.
by Mike Smart
Tweet this: Onboarding for Product Management http://wp.me/pXBON-49N #prodmgmt #hiring
This post was originally published on ProductManagement2. Reprinted here with permission of the author.
About the Author
Mike Smart is Principal Consultant at Egress Solutions, a technology product management and marketing consulting firm that specializes in solving the critical product and market problems companies face.
By Anders Lisdorf
Jobs vs Gates
In Steve Jobs’ biography a chapter is dedicated to Bill Gates. Jobs and Gates initially collaborated tightly. Microsoft for example originally made Excel and Word exclusively available for Apples MacIntosh. But as we all know, Bill Gates eventually decided to make a new version of his operating system and called it Windows. It was inspired by the graphical user interface he had seen on the MacIntosh computer.
Naturally Jobs didn’t like that Gates had stolen his idea and this started an ongoing animosity between them. Jobs, however didn’t dislike or envy Microsoft as a business, he simply had a problem with how they designed their products, which he thought lacked style and finesse.
We hear about how the first version of Word and Excel were ridiculed by Apple engineers and how the first version of Windows was unanimously mocked by the press. In both instances, however, the Microsoft team was very fast and efficient in correcting mistakes and improving the product to something that worked.
Gates on the other hand didn’t like that Jobs had no experience with coding or any real technical experience. He put a high value on having personal experience with what you were doing.
Superficially that is interesting from an anecdotal point of view, but there is a much deeper philosophical divide between the two approaches, than what can be gleaned from Jobs mocking Gates’ lack of style. Let’s start by noting that Microsoft valued experience and experimentation highest.
“the view that all concepts originate in experience, that all concepts are about or applicable to things that can be experienced, or that all rationally acceptable beliefs or propositions are justifiable or knowable only through experience.”
“Empiricism in the philosophy of science emphasizes evidence, especially as discovered in experiments. It is a fundamental part of the scientific method that all hypotheses and theories must be tested against observations of the natural world”
This is the philosophy that fueled the industrial revolution and this is the approach used by Bill Gates and Microsoft. It is based on experience with coding and experimentation is the way to find out how to make the optimal product.
But what about Steve Jobs? If he is evidently not an empiricist, then what is he? He was very inspired by buddhism especially zen buddhism. He travelled through India in his youth and was eventually married according to Zen ritual.
Now, according to buddhist writers the material world, we have access to through our senses, is an illusion. Concepts exist before and independently of the experienced world. In western philosophy this is similar to the epistemological position known as idealism. The other major epistemological school in philosophy championed by Plato.
Jobs had a vision of how the product had to be. He also made several attempts at producing the product, but here the purpose was to get closer to an already existing idea of how the product should be. The attempts were not experiments in the scientific meaning of the word, but mere materializations that could be measured against the immaterial idea.
How to make new products
So, finally we have come full circle. The disagreement between Jobs and Gates on how to develop technology was not just a superficial disagreement about lack of style or coding skills. It was about whether the best way to develop a new product was obtained through vision and thought or through experience and experimentation.
Beneath the difference between two of the worlds largest technology companies lies a century old divide between empiricist and idealist philosophy. Both have been very successful, but in radically different ways.
In software development today the winds are blowing the empiricist way. The Lean Startup movement focuses on experimentation. Start-up after start-up put their ideas into the world quickly in bad shape and experiment, like Microsoft, to arrive at a product that is good enough to satisfy a market.
If followed correctly, it can lead to good products, but it will never in itself give you amazing products. If you are fumbling along in the dark with sequential A/B test designs and random hypotheses, you will arrive at products that are good enough to generate money for your company. But in order to create something truly great you need the ability to soar above the terrain in the sky; you need to have vision.
NOTE: This article was originally published on Opaque Parcels. Reprinted here with permission of the author.