Posts Tagged “feature”
Today, we are hearing from Luis Rojas, Director of Product Management at StrongMail Systems. Luis is a Product Manager who has his feet firmly planted in the realm of Technical Product Management, which is a slight departure from the more Marketing-focused Product Managers that we have spoken with in the past on the Product Management Question Corner.
Q: What was your worst Product Management mistake and how did you recover?
A: Early on, I assumed that a sales channel that had been successful in selling one type of product would be successful selling a higher end solution to the same customer base. The company that I worked for was selling a very successful mid-tier product line through an indirect sales channel. This allowed us to put a lot of feet on the street while keeping the overall cost of sales down. The company was obscenely profitable and was selling circles around the competition. Then we had our IPO and started on an acquisition “binge.” We started buying up companies that had complementary products and proceeded to integrate these into our product family and sell them through our existing channel.
The problem arose when we started making too many demands of the same channel and diluting the message with too many products or choices. It became harder to capture the mind share of distributors because they no longer had laser focus on one solution. They became distracted by selling “suites” or “platforms” instead of trying to solve real, everyday problems.
We recovered by analyzing which distributors were being successful and why, and which ones were struggling. It became apparent that the solution was to segment distribution into a tiered channel consisting of master distributors, value-added resellers, and system integrators. This allowed each organization to focus on its own strengths and collaborate with each other.
Q: What have you done or what would you consider the best way(s) for Product Managers to improve themselves?
A: I think that the answer to this is to “be the customer” and to “eat your own dog food.” It’s impossible for a Product Manager to be successful without living through the same pains as their customers. No amount of customer interviews, surveys, focus groups, or analysts’ white papers are going to make it real for you as much as trying to solve the same problems faced by your customers. This will give you deep domain expertise. When you speak with customers, you will have a deep understanding of their issues. You will will be able to identify the complete value chain for your products and services and you will be able to turn this knowledge into effective product plans and specifications. You will be able to equip your sales people with the necessary tools to identify, qualify, overcome objections, and close opportunities. Using your own product every day will make you into an expert and will be an eye opener when you get to see all “warts” but also see all the features and value propositions that can be exploited in innovative ways.
Q: Where is the best place for the Product Management function in an organization and why?
A: I think that Product Managers have to have one foot in marketing, one foot in sales, one foot in engineering, and one foot in support. That means you’ll either have to start growing some extra feet or you’ll need to develop relationships across multiple departmental boundaries to help you gather information, come up with pragmatic solutions to problems, and drive product vision through planning into execution. The devil is in the details and if you ask ten persons in your company for product ideas, priorities, or solutions to existing product-related issues, I’m sure that you will end up with ten or more different responses. Position yourself where you can most effectively communicate the product strategy and priorities and develop internal champions that will become your allies in making your plans happen.
Q: If someone told you that they wanted to be a Product Manager what would you tell them?
A: I would first ask them why they want to be a Product Manager and then I would tell them to find senior Product Management professionals that will mentor them and help them achieve their career goals. I think that oftentimes, people have the impression that Product Managers sit around thinking up neat features to stick in the product. Later when they get into the thick of it, they realize that it’s a lot of hard work and that it’s hard to please everybody all the time. You have to balance a lot of different goals such as customer acquisition, customer retention, market leadership, profitability, increased revenues, and many others.
Q: What Product Management tool could you not live without and why?
A: I don’t think that I can narrow this down to a single tool. The tools that I seem to use most often are:
- A good word processor with the ability to create and maintain specification templates to make sure that all necessary requirements are included in each release.
- A spreadsheet to create matrices of various kinds such as feature lists, competitive advantages, product gaps, compatibility matrices, etc.
- A good source control or version control repository that will help all important documents to be centralized, versioned and backed up.
- A good defect tracking system that will help you prioritize and analyze bugs or enhancements and group them together into release vehicles.
- I also use HTML and image editors to create high-fidelity mock-ups of user interface screens or components. This helps me to not only think through requirements, but also to present various options to customers and other stake holders before writing specifications that will need to be changed later because not enough time was spent on requirements in the front end of the development life cycle.
_________
And now for Luis’ question for The Productologist:
Q: What is a good ratio of Product Managers to engineers assuming a top tier enterprise software product company with a third (or later) generation product?
A: The number of Product Managers per product or products per Product Manager is often a topic of discussion in Product Management literature, but the ratio between Developers and Product Managers is less straight forward in my mind. The average is 5.5 developers per Product Manager, but in reality, I think this number varies widely. In fact, I don’t see why the number of Developers and Product Managers should be considered together at all.
For both Developers and Product Managers, the number is primarily driven by product complexity. In early stage products, the number for both Developers and Product Managers is lower because product complexity is lower (Note: this is a generalization; the first release of a product can be very complex, but as a general rule, products start off lower in complexity and become more complex over time).
As the product matures, complexity increases, which usually requires both more Developers working on it, as well as diversification in the areas of expertise for the Dev team. Over time, the product may remain complex, but the Dev effort to maintain that complexity decreases. The effort looks much like a bell curve, though the shape of the curve varies from product to product.
For Product Managers, the number required is driven by different factors, such as domain expertise, number of products and product modularity, and the scope of the position (what the PM is tasked with), and product modularity. Let me explain each of these in greater detail:
Domain expertise comes into play in a similar way for Product Managers as it does for Developers, but for Product Managers, domain expertise revolves around the markets that the product serves vs. the technologies used in the product. Product Managers whose product serve diverse markets need to be able to understand those markets in great detail and that’s not always possible for a single Product Manager. When a single PM can no longer effectively manage a diverse pool of markets, it’s time to hire more.
The number of products that a single Product Manager can effectively handle varies based on the experience of the Product Manager, the sophistication of the the product, and how inter-related the products are. Three products per Product Manager tends to be the average, at least in recent surveys of Product Managers. On the flip side, if the product is very modular (and very large), it makes sense to have Product Managers be assigned to modules within the product. The same rules apply, but for modules instead of products. This can address the domain expertise issue, too, since Product Managers can be specialized for their module(s).
As most Product Managers know, the definition of what a PM is responsible for varies greatly from organization to organization. This is why scope is an important consideration in how many Product Managers should be staffed. A PM that is tasked with many ancillary (but critical) tasks, will have less time to focus on core Product Management functions, than one that is heads down on pure Product Management tasks. This could lead to needing more Product Managers or to bringing in staff that can handle the ancillary tasks.
So, after all that, what do we have? Development and Product Management both need to evaluate staffing based on a variety of factors, but considering the ratio between the two should not be one of those factors.
Luis had a 2nd question about structuring the Product Management organization, but I feel that deserves it’s own post, so look for that in the future.
A bit more about Luis:
Luis started his career in sales, working for manufacturing automation companies. After managing sales teams and being on the road for years, he decided to get “off the road” and stay closer to home to help raise his child. He moved into mergers and acquisitions and was tasked with managing an acquisition that required merging the product lines and channels to bring an integrated solution to market. That opportunity gave him his first taste at Product Management and, twelve years later, he’s never looked back. As a Product Manager, Luis has provided vision and leadership that resulted in long term contracts with global companies including: General Motors, Boeing, 3M, Intel, Nestle, Bausch & Laumb, Philip-Morris, and others.
Popularity: 20% [?]
Related posts
Tags: bug, Customers, Engineering, enterprise, enterprise software, feature, goals, Interface, leadership, Marketing, platform, product management, Requirements, sales team, strategy
1 Comment »
Don’t Make Me Think (2nd Edition) by Steve Krug
I have seen this book sitting on the desks or bookshelves of several designers and UI engineers that I know and it has always intrigued me. The whole concept of making the user experience so easy that it seems obvious is a big task and even with the help of books like this one, it’s still a moving target.
The book is geared toward building corporate and publisher websites, but a lot of the topics can also be applied to applications, both consumer- and enterprise-oriented software. It’s a short book (with pictures, no less), which is good. It’s laid out with some guiding principles around page layout at the beginning and then goes on to more advanced topics such as usability testing and accessibility.
Good Enough
Early on, in chapter 2, the author identifies a fundamental challenge of software development, especially web applications:
“We Don’t Make Optimal Choices. We Satisfice.”
By this, he means that we make trade-offs between making the best possible solution and one that is good enough to satisfy the user or market. Many choices that a Product Manager has to make are based on having to balance between the optimal solution and what can be done in a given time frame with the available resources. We bet that if we satisfice, it will be enough to address the short-term requirement or at least buy some time to refine the feature in a later release.
Krug later identifies some other best practices, again focused on web sites rather than web applications, but many of them apply to both, including the following gems:
- Using common navigation and organizational conventions
The less time users spend trying to figure out about your site/app, the happier they will be
- Limiting the use of text-heavy instructions
If your instructions are more than a few sentences, go back and fix your process or workflow, because that’s where the root of the problem is
- Telling visitors about your site/application
Don’t assume that everyone who arrives at your site/app know what it’s for and what it does
- Creating an obvious starting point
The home page is precious real estate, so there is going to be some crowding; make sure users know what to click
They seem like no-brainers, but both web sites and applications sometimes forget about one or more of them in the rush to create a unique experience of the user in “the next big thing.”
And Now a Word About Users
In latter part of the book, Krug dedicates some space to Usability, a subject that is near and dear to me, but which is often overlooked due to lack of time, space, money, know-how or resource availability. He starts off by debunking the myth of the “Aveage User.” The Average User is a tool frequently used to make trade offs for a website or application. Unfortunately, building software for the average user typically ends up creating mediocre software that addresses no one’s requirements.
Krug also discusses the ins-and-outss of usability testing, drilling home the message that focus group testing is NOT usability testing. It’s great that testing is included as an integral part of design. I have heard (and lived a few) horror stories about re-design projects where 100% of the effort is allocated to page layout and supporting graphics, and ZERO effort on determining if the changes are an improvement over the existing version. Oh, there’s a lot of review and feedback, but it doesn’t come from users; it comes from people within the company, most of whom are NOT the target user.
In addition to the “why,” the author spends a good deal of time outlining the “how” of testing. Beyond just providing the steps to take, Krug provides a sample script that highlights how even a bootstrapped organization can do minimal testing to improve their product.
The book closes with a chapter on how poor usability can zap user goodwill toward your software. We’ve all been there. You go to a site or web application that looks interesting, but after 10 minutes, you are so frustrated that even if the site provided all of the answers to the great questions of the universe, you wouldn’t go back. He highlights some of the most common goodwill killers:
- Hiding information
- Asking for unnecessary information
- Szzle for Sizzle’s sake
- Making users jump through hoops
- Looking like an amateur
Recommendation: This book is one that Product Managers should read once and then give/loan/purchase for their Engineering VP/Lead/Developers. It’s easy to understand, provides both context and supporting data, and it’s short. You (or an Engineer) could read it in one night.
Popularity: 56% [?]
Related posts
Tags: applications, Book Review, consumer, Engineering, enterprise, feature, feedback, goodwill, guiding principles, page layout, process, requirement, Requirements, Satisfice, steve krug, trade offs, trade-off, UI, Usability, usability testing, user experience, web applications, workflow
1 Comment »
The ladies are going for a hat-trick with this third installment of the PMQC. Today we’ll hear from Carol Dirig, Senior Director of Product Management at NewScale, a provider of IT Service Catalog and Service Portfolio applications.
Q: How did you come into the role of Product Manager and was it planned?
A: Like most Product Managers (of my generation at least), this wasn’t an explicitly chosen career. I didn’t know what Product Managers were supposed to do, since my observation of them varied from PM to PM. But they all looked very busy, very stressed, and very popular.
I was working for a newspaper company in the early 90’s and just worked my way into Product Management roles as they developed applications to deliver news and market quotes to trader’s desktops. The Product Manager role was more fluid back then. There wasn’t much of a prescription for Product Management, so it was easy to weave your way into the job and react to what needed to get done.
I think Product Managers entering the profession today have a great advantage to kick off their careers – more college business courses that bring awareness to the explicit role of Product Management, and companies like Pragmatic Marketing that focus exclusively on the tools and functions of our craft.
Q: What are the biggest challenges you have experienced as a Product Manager and how did you overcome them?
A: Time management, time management, time management. As a Product Manager you are a magnet – a catchall – for the entire cross-functional chain. Most Product Managers have a certain character that attracts them to the profession, and that character is what makes it impossible to accept mediocrity in your work, or to say “No” when you’re already operating with an overflowing plate. When you start your day with 7:00am bug triage with India, run to an analyst briefing at 10:00, painstakingly enter demo data before 1:00, submit staff performance reviews before 3:00, do two sales calls before 5:00, squeeze in a doc review before running to a cocktail reception for your user group at 6:00…it becomes a little nutty. You have to accept that on any given day, at least one person will be very, very mad at you. That is hard, given our character.
I haven’t found a great solution to this yet – but a strategy that seems to work the best is simply keeping a firm grasp of your product’s vision in mind as you prioritize the events that come barreling at you. And being sure to put time in your day to be proactive in planning the right events/work/conversations around your product.
Q: Where is the best place for the Product Management function in an organization and why?
A: I think Product Management works best as a separate function. Have a VP of Product Management on par with the VP of Engineering, VP of Marketing, VP of Sales. Couching it under Engineering has a tendency to snuff the business thinker in favor of those who are more technically savvy. Reporting to Marketing has the opposite effect.
If Product Marketing is part of the Product Management function, there’s certainly a good reason to keep it in marketing, but I’m a fan of separating these functions. A Product Marketer needs a very separate skill set than a Product Manager, and both functions have more than enough responsibility to demand disciplined focus.
Q: How do you see the role of the Product Manager changing in the next 5-10 years?
A: I think Product Management will become a more defined profession, with clearer boundaries and objectives. It’s already come a long way since I started in this job, but it’s still not quite the same as being, say, a programmer or sales executive. There has always been ambiguity around the boundaries of our responsibilities (how we define our personal MBOs, for example) but I see that diminishing. I think titles within the trade become clearer so we have a more common playbook to set up our product organizations (e..g where do the responsibilities of Product Marketing end? What does a Technical Product Manager do? How does a Product Line Manager differ from a Director of PM?)
At the same time, our responsibilities continue to grow. I think there will be more business sense brought into the role. I’m a software Product Manager, so in my experience, we hire Product Managers that come from the technical side; gifted engineers that want to change careers, or sales engineers who want more product control and exposure to management. Over the last few years, however, I have seen a trend for finding Product Managers that (in addition to technical aptitude) have a better understanding of market dynamics, pricing theories, and roadmap strategies. I think this will evolve even further so that the Product Manager profile leans more towards the business and less towards engineering.
Q: What is your greatest Product Management achievement?
A: Releasing my first product was quite a thrill. The feeling of watching customers use it (and enhance it further) over the months that followed was indescribable. Standing in front of 3000 people as they applaud the fact that your product can solve a problem they’ve been suffering…it’s breathtaking. That’s what being a Product Manager is about, in my mind. Some Product Managers are in this job because they love being the center of everything and have CEO ambitions. Others are here because we love to solve problems and watch the solution unfold in surprising ways. I’m in the latter category.
Q: What Product Management tool(s) could you not live without and why?
A: My ears. It sounds so simple, but it took me awhile to actually figure out something so obvious. Understanding the meaning behind what you’re hearing is critical to Product Management. When a prospect or customer describes a problem to you, they do so with the only words available to them, words that are common in their company, in their industry. Their description might be covering up the real – more pervasive– problem that needs a valuable solution the market would eagerly pursue.
In terms of practical tools, I’m of fan of applications like QualityCenter, and good old Excel. Anything that let’s you trace your use cases to requirements to features to test cases to doc. There are a variety out there in varying degrees of sophistication. Go for a simple tool that everyone can use easily.
I also find collaboration tools (e.g. SharePoint) invaluable for tracking customer conversations and market research in ways that let Product Managers (and cross-functional teams) benefit from each other’s knowledge.
—————-
And now for Carol’s question for The Productologist:
Q: Have you ever met a Product Manager over 45?
A: When I first saw the question, I was half expecting that there might be some sort of punch line if I scrolled down a bit more (something like, “A Product Manager, a Software Engineer and a QA Lead walk into a bar….”. But kidding aside, this is an interesting question on a few different levels.
Product Managers as individual contributors tend to be younger, typically mid-twenties to mid-thirties, but if they stick with it, they usually end up as a line manager or director (managing other Product Managers) or moving into something adjacent to Product Management, such as Product Marketing or Program Management, depending on where their strengths lie.
Product Management is a tough gig. I don’t mean that it’s harder than being an Engineer or in Sales or Marketing or whatever, but there is an emotional component to Product Management that is not as pervasive as in other functional areas of a business. That aspect can take it’s toll on anyone and for that reason, there is a general career flow from being an individual contributor in Product Management to positions that still have a Product Management focus, but have less of the day-to-day emotional investment.
There is also the fact that Product Managers are in a great position to observe and interact with a majority of the business functions within a company and more than a handful make the leap to either start their own companies or joining executive teams at startups where they have oversight of Product Management, if not direct responsibility.
Having said all of that with out actually addressing the original question, I DO know at least one Product Manager who is over 45. He’s actually a director, but is still very much involved in day-to-day PM work. He hasn’t always been in Product Management, so maybe that is the key to growing up in Product Management.
A little more about Carol:
Carol has over 15 years of experience in software Product Management. Her career began on Wall Street as a product analyst for financial information applications before moving to Silicon Valley where she has held various Product Management roles for solutions in the enterprise IT space.
Popularity: 49% [?]
Related posts
Tags: applications, business functions, Customers, demo, enterprise, executive team, feature, interact, market research, performance reviews, pragmatic marketing, product management, product marketing, requirement, roadmap, SIG, software product management, Time Management, tools, UI
2 Comments »
Following in the footsteps of great Product Management bloggers like Jeff Lash and Derek Morrison, I am introducing a new feature on The Productologist: the Product Management Question Corner or more informally known as the PMQC.
The purpose of the PMQC is to introduce some additional viewpoints about Product Management to The Productologist. Not because I don’t like my own views, but because diversity is important and hearing about and discussing contrasting viewpoints makes for a better product and a better Product Manager.
Over the coming weeks, I will be interviewing a variety of Product Managers in both software and service industries to get their opinions, insights, and experiences on a wide range of Product Management topics. Plus, these folks will be Product Management professionals who DO NOT already publish PM content on the web, so you know that their responses will be fresh!
Each interviewee will answer 5 questions and, in a perverse twist that I am sure will be co-opted by the major media outlets soon, get to ask The Productologist any question of their choosing. Maybe it will be related to Product Management, maybe not (any responses to questions about full-contact knitting or . I will include their question and my response when I post their responses.
I have a moderately-sized list of folks who are already lined up to participate, but if you are interested in being one of the lucky few, feel free to send me a note @ pmqc [at] theproductologist [dot] com.
Popularity: 44% [?]
Related posts
Tags: diversity, experiences, feature, insights, interview, product, product management, software, viewpoint
1 Comment »
The end of summer is here, so posts are a bit fewer and farther between, but here’s some good stuff to keep you busy until the pace picks up again in September.
- Changing Jobs in Product Management: Part 2
[Product Beautiful]
- Competitive Bulletins
[Product Management View]
- Protozoa and Product Management
[The Cornice]
- Enterprise Agility–The Role of the Product Owner
[Scaling Software Agility]
- Are You Decent? The Naked Truth About Product Management Performance
[Red Canary]
- New Product Development & Project Management
[Arun Kottolli]
Disclaimer: Just because I include a link to a particular posting, that is not an indication that I agree with the original author. In fact, I may post topics that are the opposite of my views or at least somewhat controversial in order to provide a contrasting viewpoint to the one I present on The Productologist.
Popularity: 58% [?]
Related posts
Tags: agile, art, blog, changing jobs, community, competitive, development project management, enterprise, evaluation, feature, HR, interview, new product, performance, plan, product, product development project, product management, project, software, unity, viewpoint
No Comments »
Folks, we’ve got a really great show for you tonight. Johnny Travers and his singing salamanders are here and later you’ll hear the comic stylings of Johanna Elenore Quiznot, but first, take a look at these postings from around the Product Management world…genius, just genius.
- You Don’t Really Own Your Roadmap
[Product Beautiful]
- Musical Chairs
[On Product Management]
- The Product Management Manifesto
[Write That Down]
- The Software Product Management Blues
[On Product Management]
- UX and Product Management
[Commadot.com]
- What are you selling? Product, category or need?
[Product Management Tips]
- Should I get product management certification?
[Ask a Good Product Manager]
- The leadership role of product management
[Lead on Purpose]
- Challenges of Off-Shored Product Management
[Confessions of a Digital Immigrant]
- Requirements data: Use cases, not features
[Forrester Blog for Technology]
Disclaimer: Just because I include a link to a particular posting, that is not an indication that I agree with the original author. In fact, I may post topics that are the opposite of my views or at least somewhat controversial in order to provide a contrasting viewpoint to the one I present on The Productologist.
Popularity: 72% [?]
Related posts
Tags: art, blog, challenges, feature, HR, leadership, leadership role, management certification, management tips, Manifesto, product, product management, product manager, productivity, purpose, requirement, Requirements, roadmap, software, software product management, technology, UI, Usability, ux, viewpoint
No Comments »
 Fast Company magazine has a feature that I like called Next Sketchpad where they highlight how a company uses design to solve product or service issues. I was looking back through some past issues and the November 2007 issue covered Trek Bicycles and their challenge to expand beyond enthusiast road and mountain bikes into making bicycles for non-bikers. They were accustomed to collecting feedback from biking professionals, but when they solicited requirements from people who weren’t bikers, they ended up designing a bike which appealed to a completely different rider.
Trek has a long history of creating bicycles for riding enthusiasts, including 7-time Tour de France winner, Lance Armstrong, and even though they already had a line of comfort-bikes, they admitted that they knew very little about the needs and desires of casual riders.
So, to better understand that market, they started asking some questions. They evaluated the overall look of the bike, wanting it to appear familiar, but still have a look that exuded comfort and cool. They also wanted the bike to be easy to use so that the barrier to adoption would be lower. To that end they included a gear system that automatically shifted based on the speed of the bike and added storage in the seat so that the bike didn’t require a cumbersome saddlebag system.
With a casual rider, the technology-side of the bike is less important to the rider, but still necessary for the ride. To that end, Trek made efforts in the design to hide many of the technical features from the user so that they would not be overwhelmed by the technology-side of the bike.
The whole exercise of Trek evaluating the needs of non-bikers is an interesting one for Product Managers (specifically software PMs). So frequently we focus on only a single market or verticals where we can “re-jigger” our products to suit the needs of a slightly different, but ultimately similar user.
Trek embarked on this product because they felt that sales for their traditional bikes was plateauing and they needed another revenue stream to maintain their growth. An interesting question for Trek and for Product Managers in general is, “Where is the point when you shift focus from an existing (or single) product to a new one?” Is it at the end of the growth curve or the middle? I would argue that it’s the latter, but recognizing that and executing on it or two very different things.
Popularity: 62% [?]
Related posts
Tags: adoption, Design, enthusiasts, feature, feedback, requirement, Sports, Tour de France, users, verticals
3 Comments »
 I had another visit with one of my customers the other day (I know, I’ve been writing a lot of posts about customer visits, but they are important and I learn a lot from them). I call them MY customer, because they are using a product that I am responsible for. It’s important to view yourself as one of the “owners” of the customer because as the Product Manager, you are responsible for their satisfaction, currently and in the future. If you are not getting out into the field to talk to your customers, both satisfied and frustrated ones, then you are missing out on valuable feedback on how to improve your product.
This particular visit was coordinated by our Account Executive at the request the VP of Engineering. He (the VP) wanted to talk to technology-savvy customers and invited me along, as I have been pestering just about everyone to go with them on customer and prospect calls.
The purpose of the discussion was two-fold:
- A knowledge exchange about each of our product roadmaps and how the customer plans to use our product
- The opportunity to hear first hand about some of the challenges (and successes) that the customer has had with the product
Part 1 was pretty straightforward. They presented the overview of their operations and how they planned to integrate our product. I then gave them a view of our product roadmap.
I call it a view, because when I present the product roadmap to customers and prospects (under NDA, of course), I don’t show them the raw version that I use to prioritize and work with Engineering on. Not because I have something to hide from them, but because for folks who are not intimately involved in the roadmap process, there is a lot of noise in the document that would likely cause confusion and/or would not be useful. There is also some customer information in it that I use for tracking purposes that I don’t feel comfortable sharing with other customers, even under NDA.
The view that I let them see is one that highlights features and capabilities with a long view. The goal is not to show them what is in any particular release, although I do share what is going in to the current and next major releases, but rather the long view.
The long view is a window into where the product is going. For an enterprise infrastructure product like mine, that means identifying how customers are going to be using the product over the next 4 years because unlike software or Web services, they are not likely to abandon the purchase without a truly significant reason.
Our customers don’t say, “We like your product, but a competitor of yours has a new feature/lower price/new UI, so we are switching.” Instead, they say things like, “We paid $X for your product and we expect it to be able to do Y” or “We like the core feature set of the product, but we plan on doing X in the future and we want the product to enable/support that.”
To answer inquiries like that, I have to be able to show them where my product is going in the future. I use the roadmap as a tool for communicating that with them. As part of that discussion, I can solicit the prospect or customer on what they view as important, which helps me understand their real-world needs.
Part 2 of the discussion involved listening to their problems with my product. As easy as it sounds, this is a challenge for many Product Managers. Product Managers are sensitive to criticism of their product (I’m as guilty of this as the next PM). We instantly try to frame any problems as “workable,” by which I mean that we try to identify ways that the user could achieve their goal within the current product framework. This sometimes helps in the short-term, but it precludes you and the customer from thinking about the real solution.
Instead of trying to whitewash the situation, a technique that I use is one that I learned back in grad school when I was studying Counseling Psychology–Active Listening. This suite of listening skills allows you to be more engaged in hearing what the other person is saying rather than debating points back and forth. It is very validating for customers when you, as the Product Manager, just acknowledge the issue that they are having and listen to what they have to say about it.
Lack of defensiveness on the part of the Product Manager creates an environment where the customer is more likely to provide you with valuable input, because they don’t have to waste time and effort in arguing their point.
I won’t kid you, it’s a LOT HARDER than it sounds and the first few times you try it, it’s not only painful, hearing all of that “feedback,” but it takes a lot of effort not to respond. But, I promise that if you keep at it, you will get so much great information that you can use to improve your product that you’ll wonder how you ever collected any useful user feedback without it.
Popularity: 59% [?]
Related posts
Tags: challenges, communicate, customer, Documentation, feature, feedback, knowledge exchange, Prospects, roadmap, satisfaction
2 Comments »
This is a new feature that I am trying out. On a regular basis, I’ll write a post with a collection of interesting (at least to me) postings from other Product Management blogs. It’s intended to give my readers some exposure to what else is going on in the world of Product Management and to spur some dialog.
Just because I include a link to a particular posting, that is not an indication that I agree with the original author. In fact, I may post topics that are the opposite of my views or at least somewhat controversial in order to provide a contrasting viewpoint to the one I present on The Productologist.
Here’s the first round:
- What’s Product Management like a Year after Implementing Agile
[All about Product Management]
- The Failures and Successes of Open Source Product Management
[Product Beautiful]
- 31 Flavors of Product Management in Seattle
[Prodman.net]
- Product Manager VS. Scrum Product Owner
[Agile Software Development]
- Five guidelines to prioritize feature requests
[Product Management Tips]
- Web 2.0 Product Management: Optimizing Metrics & Viral Growth
[Master of 500 Hats]
Popularity: 35% [?]
Related posts
Tags: agile, feature, feature requests, management tips, metrics, open source product, scrum, software, viewpoint
No Comments »
I went to visit a customer a few weeks ago as part of a commitment to myself (and my products) to get out into the field more often. My goal with them and with all of my planned visits to the field was to talk about how they use my product, what business challenges they face and what they see for the future in terms of their own growth and what they would want and need from my product. I got what I was looking for…and a whole lot more.
Unlike many of my colleagues in Product Management (at least in software Product Management and in the Silicon Valley), my educational background is not in Business, Marketing, or Engineering. Both my undergraduate and graduate work were in Psychology and Counseling Psychology. I didn’t learn a lot about financial models or the 4 P’s of Marketing or how to write Java code (though, I did learn about the Internet, primarily through it’s forebearer, Gopherspace), but I did learn the importance of listening.
One of the primary tenets of Psychology, be it clinical, research or counseling, is that you have to listen more than you talk. If you are working with experimental subjects, you have to listen and document their responses. If you are working as a Psychotherapist, you typically spend 40.5 of the 50 minutes of the “therapist hour” listening to your client. And not just listening to what they are saying, but listening for the hints and hidden messages behind what they are saying and deciphering their context and meaning, which is the key to successful talk therapy.
As a result, listening is a skill that was hammered into me repeatedly for 6 years and has come to be a valuable tool for me as a Product Manager. When talking with customers, prospects, Engineers, Salespeople, or the Executive team, I listen first. I make sure that I understand not only what is being said, but why it is being said, the context and whether there is or might be any sub-context (which is really just another way to say “reading-between-the-lines”). Once you start listening, you’ll realize that the person or people talking are giving you much more information than you originally thought.
Which brings me back to my original point about the customer meetings. As I mentioned earlier, I was just looking to get some very high-level information that I could normalize with all of the customers that I was planning to meet with. I had never met with this customer before, but had reviewed some of their past and current support tickets to get a cursory understanding of some of the issues that they faced. I had also talked with members of the Support team to get their view of what type of customer they were and the relationship that they had with our company.
Based on the preliminary data I had collected, I was prepared for a somewhat painful meeting with the customer. I didn’t think they were a very good fit with the characteristics of our “ideal” customer and the features they were asking for and the issues they brought up with Support were considered by me and others to be edge cases.
The original plan was for me and one of our founders and the VP of Engineering to visit this customer, but due to some last-minute scheduling conflicts, it ended up being just me. I thought about changing the meeting, but it had been hard to coordinate in the first place, so I decided to see it through. When I got there, however, and started talking with the team, my perceptions about them started to change.
First, after about 30 minutes, I had a better understanding of their business, which was considerably different than what I thought it was before the meeting. Having that understanding made many of their issues seem less like edge cases and put them more in line with some of the challenges that other customers might have. That gave me some ideas about how to tackle some of the challenges in the near-term and also what I would need to do in the future to address areas which I thought were well outside of our sweet spot, but now see as being more integral.
Another thing that happened was that while the meeting initially had a somewhat adversarial tone to it (we started the meeting by getting some of their issues out on the table, even though I had tried to steer the conversation away from that area), as I let them talk and asked only a few questions to spur the discussion, they started to discuss more about their vision and how they saw my product fitting in to that vision.
What I found was that they had many ideas on how to use my product that I hadn’t considered. They wanted to use my product in a way that it wasn’t currently being used, but that made a lot of sense when they spelled it out. It was an “A-ha!” moment for me.
Finally, through the discussion, I got insights into how another organization operates. What their processes are. How they build their product. What they spend their time and money on to increase success. What type of people they have on staff and in what roles.
It’s easy to become insulated in one’s own organization and I sometimes find that I limit myself to the same patterns of interaction and process that I have become accustomed to. Hearing the stories of this customer (and others) helps me to lift my head up from looking at my feet while I walk and take a fresh view of the world.
Plenty of Product Management texts and resources recommend talking to your customers in order to build better products, but there’s also a good possibility that just listening to customers can help build better products and better Product Managers.
Popularity: 53% [?]
Related posts
Tags: challenges, customer, Engineering, executive team, feature, Marketing, process, Prospects, software product management
10 Comments »
|
Entries (RSS)