You can see my other sites for Product Management guidance and opinions:
Nils’s Personal Blog
2016 – More Hardcore Product Management Ahead
Calendar, by Joy (CC 2.0 license)
The turning of the calendar itself has no real meaning, but it does give us a chance to reflect on what’s gone before, and what’s ahead. In my last post I reviewed the topics we covered in 2015. This post is about where I’ll be focusing in 2016 in terms of becoming a more skilled product manager, and in helping others achieve that. I already “practice what I preach” on all those topics, of course. But there’s always room for improvement, and as I’ve mentioned lots of times, getting more effective at product management has a huge ROI.
Systems
But instead of focusing on that goal this year, I’m going to focus on a system for being a better product manager. This approach is inspired by several writers and speakers I heard this year, including James Clear and Dilbert cartoonist Scott Adams (on his blog and on on Tim Ferriss’s great podcast).
The idea is the system is what gets you to the goal. You still have the goal (maybe), but you pay attention to the system. These other guys explain it better than I do – for example, James Clear illustrates the difference between goals and systems like this:
- If you’re a coach, your goal is to win a championship. Your system is what your team does at practice each day.
- If you’re a writer, your goal is to write a book. Your system is the writing schedule that you follow each week.
In 2016 I’ll be working on my system for being a more effective product manager. As my new and updated system components unfold, I’ll report back.
Deliberate practice
The other big focus for me this year is “deliberate practice.” Deliberate practice is a key part of Kathy Sierra’s “badass” concept, although I didn’t go into great detail on in my badass-related posts.
If you want to become better at something, you have to practice – it’s true of skiing, it’s true of photography, it’s true of playing a musical instrument. And it’s true of professional careers as well – surgeons practice a lot, and so do lawyers. And practice is not just “doing the job.” As Kathy Sierra says in her book Badass:
Only a specific type of practice makes perfect, and in the science of expertise, it’s known as “Deliberate Practice.”
James Clear says, building on Kathy Sierra’s description:
Deliberate practice is when you work on a skill that requires 1 to 3 practice sessions to master. If it takes longer than that, then you are working on something that is too complex.
There are examples in the literature of doctors performing deliberate practice, and of course top musicians do a ton of it. But I haven’t heard of a pedagogy for product management that uses deliberate practice. It seems worthwhile to focus on this for a while, both for myself and for the product management community as a whole.
Some examples that have come to mind so far:
- Making phone calls to stakeholders – this is actually something I’m not as skilled at as I’d like to be. Once I’m on the phone I’m fine, but it’s more of an effort for me to pick up the phone than it should be. So I think deliberate practice will help me with this.
- Entering defects – this is something we all have to do as product managers, and I’ve actually done quite a bit of practice on this one.
- Various situations where deliberate practice will take the form of role playing: breaking bad news to a customer, telling a sales person that the product can’t do what they just promised a prospect, breaking the news of a schedule slip. Those are all bad situations, but it will probably pay off to do some practice on how to make the best of good results as well – writing an effective company email to share an exciting customer success, for example.
I will develop a set of these small product management activities to practice, and then determine the forms that the practice will take. And then do the practice myself over the course of the year. It should be very interesting. And I suspect my skills will be much more developed at the end of the year.
2015 Year In Review – Hardcore Product Management
Sparkler
Looking back over 2015 on this blog, I see quite a lot of meaty content! The topics have been hardcore product management-related. I hope you’ve enjoyed reading it as much as I’ve enjoyed sharing it.
Summarizing (with links to the key posts), we went deep on:
- The business value of product management, and how valuable it can be for you to improve your effectiveness as a product manager.
- A series on how to be a badass product manager, using ideas from Kathy Sierra’s Badass book.
- 6 podcast episodes from the first series, and 4 from the new series.
- What does a product manager do, anyway? And how does it relate to marketing, anyway? And the right way to use stories from your customers to sell more.
- The importance of finding and validating market problems, and how to do it.
- What to do if your release is running late, and how to mitigate that in the future.
I even put a product management maturity quiz out there, just for fun.
I have lots more thoughts to share in 2016. Tomorrow I’ll share some ideas on how I’m going to run things in 2016 so that more of my thoughts make it out into the blog and into the world. (The key word is “systems.”)
Interview With Hubert Palan, CEO of ProductBoard, Part 2 – Podcast Season 2, Episode 2
This second part of our interview with Hubert Palan is the third episode of our new podcast season of All The Responsibility, None Of The Authority, crossposted from alltheresponsibility.com. I will be crossposting the new episodes from the new site to this feed as they are published (I’m a little behind now but will catch up!).
This is part two of our interview with Hubert Palan, found and CEO of ProductBoard, and long time product management leader and executive.
Part 1 of the interview is here.
Three things you can start doing today
As always, we like to give you actionable takeaways from our podcast episodes. The three ideas below come directly from our interview with Hubert.
- Create a central repository, not just about the features you’re building, but about the market inputs you gather to help you find and validate the business problems you are solving. You can use a tool like Hubert’s ProductBoard, or you can try to roll your own (Nils had a podcast about this last year). This information comes from Support, Design, Product, Sales, Marketing, and your own conversations with customers and prospects. A central store of this input, and the relationships between this information and the product decisions it supports, helps mitigate some of the cognitive biases Hubert mentioned. And by gathering all this information together, you are better able to detect market signals in all the noise, and make better holistic decisions about the product.
- As Hubert pointed out many times in the interview, Context is King. Make sure your team, and your whole organization, knows not just what features you’re delivering, but what problems those features solve, and for whom. This not only simplifies many of the issues of prioritization, it also serves as a basis for communicating across segments of your organization.
- Clarity and communication are the heart of the Product Leader’s role. The better we get at clearly communicating about prioritization, context, and decisions made in the product team across the organization, the better the organization can execute on creating and selling solutions to customers.
Thanks to Hubert!
Rob and I want to reiterate our thanks to Hubert for participating in our new podcast as our first interview! If you want to learn more about ProductBoard, you can visit productboard.com. You can follow Hubert on Twitter at @hpalan, and ProductBoard tweets at @productboard.
As always, we’d love to ask two small favors from you:
- First, please subscribe to the podcast on iTunes, or wherever you get your podcasts. You can access the podcast directly on this feed.
- Second, please rate the podcast on iTunes or “recommend” it on your podcast app.
Finally, we really appreciate getting your opinion, so we’d love to hear from you in the comments, or via Twitter (@atrnota) and our Medium publication, All The Responsibility.
Podcast: Play in new window | Download
Interview With Hubert Palan, CEO of ProductBoard – Podcast Season 2, Episode 2
Here is the second episode of our new podcast season of All The Responsibility, None Of The Authority, crossposted from alltheresponsibility.com. I will be crossposting the new episodes from the new site to this feed as they are published (I’m a little behind now but will catch up!).
Introducing Hubert Palan
Nils first met Hubert Palan in November 2014 at the Product Management Summit in San Francisco. Nils was presenting some ideas on a “roll your own product management system of record,” while Hubert was there to talk about the product he was building – a real product management system of record. This product, ProductBoard, is now available, and it’s definitely worth checking out. Hubert is a serial entrepreneur, with innovative and incisive ideas about how product management as a discipline can be improved.
In this wide-ranging interview, we discuss Hubert’s background, how he moved into product management, his career at Good Data, where he was the VP of Product, and his decision to leave Good and start ProductBoard.
This post is Part 1 of our interview, Part 2 is here.
Three things you can do today
As always, we like to give you actionable takeaways from our podcast episodes. The three ideas below come directly from the first part of our interview with Hubert.
- Get in the problem space, not the solution space. Immerse yourself and your team in the problem that needs to be solved. Then, don’t devote so much of your time to the design and the solution – that’s a job for designers and engineers. Your advice and review is valuable, but your focus should be articulating the problem, then giving the rest of your team space to solve it.
- Turn your company or tribal knowledge into a system. It’s valuable even before it’s perfect. Think about team knowledge, the captured information you have, as something that deserves a system of record. Hubert described how difficult it is to simply use your memory for this, especially when it’s more than just you on the team. Of course, you can take a look at Product Board, but as Hubert pointed out: the system matters less than simply getting something in place.
- Finding the problem is orders of magnitude more important than how efficiently you can create a solution. Although it’s hard and not very well-defined, the process and results of focusing on the problem first will save time and frustration for many cycles to come, and often result in better product performance. So spend time distilling the problem from every angle, and share that with the entire product team. It will act as a beacon of light to follow.
Thanks to Hubert!
Rob and I want to reiterate our thanks to Hubert for participating in our new podcast as our first interview! If you want to learn more about ProductBoard, you can visit productboard.com. You can follow Hubert on Twitter at @hpalan, and ProductBoard tweets at @productboard.
As always, we’d love to ask two small favors from you:
- First, please subscribe to the podcast on iTunes, or wherever you get your podcasts. You can find the podcast directly on this feed.
- Second, please rate the podcast on iTunes or “recommend” it on your podcast app.
Finally, we really appreciate getting your opinion, so we’d love to hear from you in the comments below, or via Twitter (@atrnota) and our Medium publication, All The Responsibility.
Podcast: Play in new window | Download
All The Responsibility None Of The Authority Podcast – Season 2 Is Here!
My ATR-2100 Mic and Mac laptop – where the magic happens!
It’s been just over a year since I started All The Responsibility, None Of The Authority, the podcast for product managers, product marketers, innovators, and entrepreneurs who want to be more effective and more successful creating and selling products.
I published a total of eight podcast episodes – not terrible, considering that most podcasts end on or before their seventh episode. So I beat the point spread!
And those were pretty meaty episodes – about product management systems of record, about the business value of product management, about a new way to think about product “requirements.” But for the second year of the podcast we’ll be a little more ambitious and get a lot more content out than the first year. Of course, still with the meatiness, the immediate applicability, and the powerful new ideas. So we’ve relaunched the podcast for Season 2. I say “we” because I’m joined by a new host! Rob McGrorty, product guy at Webgility in San Francisco, and an all around cool dude.
The other big change is a new website to host the podcast, along with a new podcast feed. The first three episodes are now up on our new site, http://alltheresponsibility.com. You’re reading this because I will crosspost new episodes to this site – and this feed which you’re listening to – as well. If you’re an existing subscriber you don’t need to do anything to get the new season with me and Rob. So you can keep your subscription here, or if you like, get the new feed from alltheresponsibility.com.
As always, we have our “three things you can start doing today to put these ideas into practice.” We want to give you concrete actions you can take from each of our episodes, which is a great savings in your cognitive capacity. (We’ll be doing a podcast on cognitive capacity and its implications for product managers later in the season.)
Let’s get on with the new season! This is the short introductory episode, introducing Rob. And there are two more episodes following that, a very interesting two-part interview with someone I think is solving a very big problem for us product managers, as you’ll hear.
And since today’s episode is “introduce the new season,” and this podcast help you become a better, more effective product person, the three things are focused on making sure you get every episode, and that every episode is as full of actionable content as possible.
- Sign up for our mailing list on http://alltheresponsibility.com. You can also easily subscribe to the podcast at alltheresponsibility.com/itunes, which definitely will give you insights on how to be a better product manager
- Write us a note in the comments, a tweet (@atrnota), an email, or leave us a voice message on the website with your ideas for what we should cover and whose insights you want to hear (that is, people we can interview). Let us know, good or bad, what we’re doing right and what we’re doing wrong.
- Give us a rating on iTunes, tweet about the podcast, or otherwise share your thoughts and – hopefully – recommendation on this podcast with your tribe. The better everyone gets as product managers, the better off we all are.
Podcast: Play in new window | Download
What Does A Product Manager Do?
When someone asks you in the future “What does a product manager do?,” instead of saying “he or she is the CEO of the product,” you can say they:
- Find a market problem (and validate it)
- Create a solution to the problem
- Take it to market
Wait a sec! That seems simple, almost like something my mother might understand.
Product Management Is All About The Money, Baby!
Most of you have the ambition to get big. How do you do that? The only way to get big as a product company is for people to buy your product. Preferably a lot of people, for significant amounts of money at a time. Duh!
But why would people buy your product? We know there are products that people don’t buy. We don’t want to have one of those – because you can’t get big, or even grow at all. If you look at the revenue line for a product that no one buys – it’s nasty! We don’t like that line at all!
Why Do We Get Revenue?
Compare it to our desired revenue line – up and to the right – and accelerating as it goes up. If our product sells like that, it means it’s solving an important problem for some people. Important enough that people will pay for the solution.
You may have a beautiful product, beautifully engineered and architected, and rocking in usability. But if it doesn’t solve a big market problem… Flat line.
A product can have some warts, not quite work as the user expects all the time, have some typos, use a 1998 style UI – but if it solves a big problem better than anything else… Up and to the right.
Problem Should Be At The Center
This is called, in Lean, “product/market fit,” or “finding a repeatable business model,” or other things. These terms suggest the product is at the center. But in truth the market problem should be at the center. That’s what drives your revenue up and to the right – a good market problem that only you solve, or that you solve better than anyone else.
Also Known As … Product Management
There’s a person in your company, perhaps multiple people, who are responsible for finding these problems and figuring out how to solve them. If you’re a small startup, this is going to be one of your founders. In a larger company, that person is usually called a “product manager.” (Perhaps this role should be called “problem manager?”)
The Rest Of The Story
Apart from finding (and validating) the problem, there are two other important things product managers do as well – less important in some sense (doing a better job of building a zero-revenue product still leaves you with zero) – but still necessary for success.
One of these is to guide the creation of the solution. This happens differently at different companies – sometimes the PM creates a full spec, sometimes a tweet is good enough to guide the engineering team. But it’s the responsibility of the PM to make sure that what comes out solves the market problem.
The third critical piece is to get the product to market. This is often called, surprise, “go to market.”
- Making sure Marketing knows who to target with programs, and knows the right messages to put out
- Giving the sales force tools for reaching those people and selling the solution effectively. (Remember, those people are anxious for a solution and willing to pay for it.)
- Providing competitive analysis and other materials so your product prevails in sales engagements
Taking Action
Here are three things you can do today to use these ideas
- Start thinking of yourself as a “problem finder” – and start to learn how to find problems (hint: Here are some posts on this blog to help you get started: Finding and Validating A Market Problem, How Badass Are You At Finding And Validating Market Problems?)
- Make sure you can articulate the problem your product solves for your market segment. (Here are some guidelines on how to do that effectively: A Weak Value Proposition Is A Symptom, Not A Disease, Do You Want To Be A Badass Product Manager?)
- Make sure your marketing and sales people understand who you’re selling to and why they should buy your product and not spend their money elsewhere. (What Is Marketing, To Product Managers?)
Summary
Product management consists of three main activities:
- Finding and validating market problems
- Creating solutions to those problems that are better than other alternatives
- Taking those solutions to market
While #2 is the most natural, for a lot of us, #1 is far more important. No matter how good your product is, if it doesn’t solve an important customer problem, it won’t sell. And if the market doesn’t hear about it, or hears the wrong thing (#3) then they won’t buy it either.
What Is Marketing, To Product Managers?
Quick take:
- Marketing, the department, is about executing the programs that deliver leads and establish brands.
- Product management, the department or function, is responsible for providing Marketing with the value proposition, the positioning, the segments to attack, and benefit/feature stories they and Sales use as the basis for those marketing programs and for individual sales engagements.
You can’t let Marketing develop the value proposition. In fact, you’d better know it before you even start building the solution, because you understand the problem you’ve solving, the segment who has that problem, and why they will buy your solution instead of doing something else with their money (the three components of a value proposition). Marketing can help refine it and articulate it, but it’s not their job to come up with it.
So, if there’s no Marketing department, guess what? You get to do the execution. If there is a Marketing department, guess what? You still have to come up with the value proposition, the segmentation, the competitive differentiation, and the benefits/features.
Thoughts? Is this how you do it?
How To Share A Roadmap Without Driving Into A Ditch
A winding road (CC BY-NC-ND 2.0
Massimo Marino)
Roadmap-related conversations exploded on various social media channels a few weeks ago. Jared Spool put up a post on Medium about a concept he learned from Bruce McCarthy – basing roadmaps on themes rather than features. (Although product managers have known this concept for a long time.) And Marty Cagan responded to the Jared Spool post with one of his own. Of course, product managers have written about roadmaps – and been on the ground making roadmaps – for a long time.
But a question on the PMHQ Slack channel piqued my interest most particularly. Someone asked: “What do you use for roadmapping?” The questioner turned out to be someone from outside the high tech/software space. She wondered how we managed our roadmaps in high tech and software.
I used the question as the springboard for a riff on the PM HQ chat board.
My attitude toward “roadmaps” and “roadmapping” for products is perhaps iconoclastic. And apparently idiosyncratic. But I hope the following practical advice will help you navigate the quicksand of roadmaps. Especially when you have to share with people external to the product organization.
What Is A Roadmap?
A common question when PMs get together is “what do you use for roadmapping?” This question can mean lots of things, but usually it means one of two:
- How do you manage the list of features that you expect your developers to work on over the next period?
- How do you present the list of features you are developing to outside stakeholders? Such as executives, other internal organizations, customers, or analysts.
Personally, I usually call #1 “the plan” rather than the roadmap.
If I’m going to share a roadmap with anyone other than dev, I make it in PowerPoint. I never want to put a) real or b) all the information in something I’m sharing externally. Not even to other people in the company, normally.
By “real” I mean “with all warts exposed.” For example, our internal plans use insider technical terms. Those depend on understanding our technology (not just the product). I don’t want to require or expect my stakeholders to make that leap.
I always sanitize what gets shared with others. And then I also move it “up a level” – or four.
When presenting a roadmap externally, I always show themes or “epics,” rather than features. I often present them as happening over a time period different from their actual schedule. If there interesting interim releases, I might show those as well.
There are quite a few constraints when putting these epics onto the roadmap. Usually I want them to be one or two words, maybe three. They need to be in non-technical language, and not domain specific. Often one box or epic on the roadmap will represent many “epics” or “features” or “chunks of value.” In our real plan, they are on their own schedules. Sometimes I separate out features that are part of the same epic because they help me tell a better story. For example, if I’m presenting to a customer who requested a specific feature, I might highlight it.
And if possible I don’t even give people that roadmap, the cleaned up one, I only present it to them. (This is often not possible.)
For example, my team’s current feature is “Staffing Requests Phase 4 – Replan/Route-To enhancements.” It’s an epic. But while it’s a meaningful name for the product org, it’s a terrible name to expose to outsiders. It would raise many more questions than it answered. So, for a customer, it’s called “Resource Management” or “Centralized Staffing.” And as such it’s combined with some other related epics that I also don’t mention. This combination of epics is a theme.
I also often will prune things off the roadmap for particular audiences. For example, if I know they don’t want some capability, I might not mention it. Or if I’m worried they’ll think it’s distracting us from their favorite thing. Or, to emphasize they are not our only customer, I might highlight a feature they don’t care about.
Roadmap Tools
There are many tools that position themselves as “roadmap tools” for product managers. Usually these are really about the first meaning I listed above – “the plan.” They aren’t oriented to “how do I present what I’m working on to stakeholders.”
In my ideal product management tool, I could make a roadmap I could actually share with stakeholders. It would start by supporting “public names” for features and themes. It would have the ability to buffer the expected delivery dates. I could edit, annotate, or hide any entries I wished. And it would put all that into a PowerPoint slide that I could load into a deck and update in real time. This is not a trivial set of things to support.
Software Is Different
The original question was from a software industry outsider. I thought it would be useful to compare software roadmaps with those of other industries. The first takeaway? Comparing a software company’s roadmap to a roadmap from another industry is apples to oranges.
Usually those other types of companies have products that obey the laws of physics, such as semiconductor makers or car manufacturers.
Conversely, software company roadmaps often present capabilities that are not even designed, much less built.
Here’s a thought experiment for you. How soon before they hit the showroom do carmakers release information about the features and capabilities of their next car models? It’s about a year if you think about it. How long does it take to get a new car feature that’s designed and developed for manufacturing to the showroom floor? The answer: about a year. When carmakers announce new features on cars, what they call their roadmap, they’ve already done all the design and development work on those features. They are not predicting the future.
How about semiconductors? Intel has a 1-2 year roadmap for its processors. How long does it take for a new semiconductor fabrication innovation to get from discovery and validation in the lab to being an actual feature on a chip that you can buy? Well, it’s about three years. Intel’s two-year roadmap is not predicting the future – they know and have proven the technology.
And even then the roadmap slips. Back in May of 2015, Intel said it would ship 10nm chips in calendar 2015. By July its roadmap had changed, with the 10nm chips pushed back to 2016.
Take action
Here are three things you can do today to improve the roadmaps you share with external people.
- Focus your roadmap on themes, not features.
- Use customer language in your roadmap, not technical or insider jargon.
- Make sure you understand the desires, needs, requests, and pains of the stakeholders to whom you are presenting, so you can fit your presentation to their expectations.
How do you use roadmaps?
Do you have techniques for sharing the future for your external stakeholders? Do you have stories about how you finessed a difficult situation? Or have you accidentally set their expectations that you would deliver something impossible?
5 Ways Product Managers Can Make More Money
I said a few weeks ago that we software product managers are responsible for $5-$10 million in new revenue over the next 12 months. How do you get that? There are five ways your revenues can increase:
- Your market grows, and you grow with it naturally
- You beat your competitors more in your existing deals – that is, you increase your win rate
- You get into more deals and win them at your normal rates – that is, you increase your sales velocity
- You extend your footprint in your existing market by selling more to each customer – or increase your average deal size
- You start selling in a new segment or market
Those are the fives ways to grow revenue. If you do enough of them, you might see your $10 million in incremental revenue in a year.
Given that those are (five of) the ways to grow revenue, what do we do about them?
Natural market growth
Your responsibility as the product manager is not for this growth, per se, but for not losing this growth. To keep your revenue growth up with market growth, you have to continue to win deals your current rate. You can’t do that by standing still. The competitors are always getting better. Just like Alice, you have to run very fast just to stay in one place, market share-wise. And even if your product continues to grow at the rate of the market, and doesn’t lose market share, you usually don’t get any product management credit.
Bottom line: growing at the market rate is table stakes, but it’s not winning.
Beat competitors more – increasing the win rate
This is also known as “taking away market share.” How do you do it? Especially if you have to do it right now and you don’t have the luxury of adding new features? This is all about go-to-market: helping sales and marketing tell the story of your product better, giving them better tools for objection handling and de-positioning the competition, creating the best possible demonstration. Bottom line, this is about doing a better job of convincing prospects that your product solves their problems better than the competitors do. If you can do that, you can win more deals.
Of course, over time you can also add features that help you in competitive situations. But you can’t do that today, so you need to use other tools in your quiver.
Get into more deals – generate more leads, increase sales velocity
How does product management have influence on more leads and faster closes? This is also a go-to-market issue. Many of the techniques you use for winning more deals can also help you get into more deals. Telling the story of your product better, especially using effective social proof showing how customers’ lives were improved due to your product.
Decreasing the time to the second sale is another important goal for getting into more deals. (New sales to existing customers are among the most attractive of all deals!) How do you get to the second deal faster? By making sure the customer’s initial experience is so successful that they can’t wait to buy more! Again, what are your options? Over time you can add features and capabilities to make the initial experience better. But in the short term you can give them better training and documentation, focused on solving the business problems your product addresses. And you can offer online videos that show how to quickly and easily do important functions.
Increase average deal size
There are tactical ways to increase average deal size, and strategic ways. For example, you can focus your sales efforts on your biggest prospects, and not pursue smaller deals. If you can win either size of deal with a comparable effort, this makes a lot of sense as a tactic. This is not so much a product management decision, although of course you have input into some of these sales decisions.
Our focus as product managers needs to be more strategic than tactical in this area. Larger deals, especially in business software, are often dependent on more “enterprise-level” features or capabilities. Those are longer term commitments from the you and the product team, and usually can’t make a short-term difference, despite their importance over the long term. But there are sometimes short-term workarounds. For example, a partnership with another vendor with a complementary product that addresses one of your enterprise-level shortcomings.
Get into a new segment or market
Now, this is where the real fun is! New products! New features! You’ve been working on keeping your product portfolio pipeline full, right? You have plenty of validated new product ideas to choose from, many of which will open new markets for your company. Some will be extensions of the existing product that will enable you to sell higher, or sell to adjacent markets. Some will be completely new products that will address completely new business problems.
Remember that for most successful product companies, 50% of their revenue comes from products introduced in the last three years – you have to keep that pipeline full and pumping out great new stuff.
Let’s make some money!
Our job as product managers is not to “make products” but to create solutions to market problems that people will buy. There’s only one reason people buy business software – to solve business problems. And there are only five ways to sell more of it.
Let me know what you think of this post. I’d love to hear your reaction – and how you’re handling this problem of making more money.
- 1
- 2
- 3
- …
- 13
- ...Next Page