Silicon Valley Product Camp 2012 is this coming weekend! March 24th at eBay’s office at 2161 N. First Street. You went to all the trouble to register and vote for sessions, so don’t forget to show up! If you’re like me make sure to warn your spouse so they aren’t shocked that you have plans for 8 AM on a Saturday. If you didn’t manage to register in time, make a note to sign up next year or try to get to one of the other awesome Product Camps taking place around the country or around the world. Check out the top proposed sessions ahead of time to see what catches you interest.
NOTE: The following is a guest post by Catherine Constantinides. If you want to submit your own guest post, click here for more information.
Is it just me or does the chorus of the Zeppelin song “Communication Breakdown” pop into your head every time you think of issues related to feedback management and communication in the workplace?
Communication Breakdown, It’s always the same,
I’m having a nervous breakdown, Drive me insane!
It’s probably just me. I digress.
One of the key components of successful collaboration is sharing feedback. Naturally, we know the importance of directly collecting feedback from customers, but what about collecting insight from internal stakeholders like Sales, Customer Service and Marketing? These units also have many suggestions and ideas on how to improve products/services.
On the front lines, they interact with customers on many levels and at different touch points. They listen and respond to customer feedback and are strategically positioned to collect and communicate valuable insights on products and services. It is therefore essential to the development and delivery of more customer-centric products that a product manager actively collaborates with these key players.
Looking at the challenges of collaboration through the lens of the product manager we can attest to the complexity of teamwork. It’s widely understood that product managers, often wear many different hats and the conflicting demands on their time are high. They are constantly fielding requests and questions from practically everyone. Sales pressures the design of new product components that meet customer demands and help them make their sales targets. Marketing needs detailed documentation to properly position the brand and products in the marketplace. Customer service sends a constant flow of questions and customer complaints that require immediate attention, and so on and so forth.
The reality is that all of this crucial information exchanged during this time often fails to get communicated or does not get to the people that need it most, in a timely way. This process breaks down even further when geographically dispersed teams are added to the mix. When information falls through the cracks or is received in an unusable format, opportunities are lost. Designing a feedback system based on the fundamental principles of collaboration between departments or diverse teams can greatly improve the flow of information within the product development process.
4 ways to harness collaboration in your product development process
Here are four things you can do to increase the effectiveness of your organization’s feedback system. The corresponding suggestions for tools help you improve collaboration in your organization:
Encourage sharing of product-related feedback across your organization
How often does Sales share critical feedback from customers? Does your Marketing team offer suggestions for product improvements? If your customer service team is receiving numerous complaints about a specific feature of your product, are you notified?
You owe it to yourself and the success of your next product launch, to take a minute and examine the entire process of sharing feedback throughout your organization. By doing so, you may uncover that the ‘silo effect’ is limiting your ability to respond quickly to important internal and external feedback. An antithesis to the principles of open collaboration across departmental boundaries, the silo effect stifles creativity and growth.
Use tools to gather and manage effective feedback
Are you buried in survey responses and complicated data from customer questionnaires? Do the tools you currently use really help you address every aspect of the feedback process? Web-based idea management tools are effective tools for capturing, organizing and elaborating on feedback. Requirements management tools help you translate large volumes of customer insight into actionable product requirements.
Tools must also be designed to facilitate bringing together internal and external stakeholders, such as business partners, employees and especially customers. This ensures everyone has a voice in the process and that feedback is accessible across departments such as Sales, Customer Support, Marketing, Product Development, Engineering and Production.
Centralize and organize product feedback
Busy defining product requirements for an upcoming product release? Having a centralized and well organized product feedback system will help ensure nothing falls to the wayside. Virtual workspaces are a great way to maintain requisite resources focused on particular topics and share their resources through collaboration.
Evaluating the effectiveness of how your product feedback is organized must be made from the perspective of the various departments and teams. Be sure to include them in establishing evaluation criteria and in performing the assessment. Everyone’s needs must be considered and everyone must participate in the design of a well organized product feedback system.
Tie feedback to the entire product development process
One of the most important elements of the feedback process is taking the collected feedback and actually incorporating it into your product or service strategy. When you explore how the feedback you collect is used at different stages of the product development process, you can uncover bottlenecks that stifle the flow of information.
Product-related data must be seamlessly integrating into the product and service development and delivery processes. This means that information captured in one stage of the product workflow is moved downstream to affect change to development. After all, feedback is useless unless someone uses it to make improvements at every step of the development process.
While it may seem impossible at times, encouraging the sharing of ideas can help transform your products into great ones. By exploring these four questions, I am confident that you can find effective and perhaps innovative ways to harness the infinite power of collaboration and avoid major “collaboration breakdowns”.
Catherine Constantinides works at OneDesk, a developer of social business applications that connect employees, business partners and customers to the product development process. She is also a regular presenter during OneDesk’s weekly webinars.
Oh…and she loves Led Zeppelin. 😉
Tweet this: How to deal with Collaboration Breakdown http://wp.me/pXBON-3cO #innovation #prodmgmt
By Saeed Khan
I can’t believe it’s been over 3 year since I first wrote this piece. It was intended as a counterpoint to all the agilists that were decrying how Product Management wasn’t “agile” (or “Agile”). I found (and still find) the whole argument somewhat baseless, but it still persists amongst agilists (look at this example of what “Product Owner” is turning into), and unfortunately, even within the Product Management community.
Those who talk about “Agile Product Management” as some unique form of Product Management are not doing anyone a service. “Agile Product Management”? As opposed to what? “Sluggish Product Management”?
Just because the technologists have latched onto something that seems to be having benefits for them — and believe me, the bar was set pretty low for many of them — that doesn’t mean Product Management needs to latch onto that as well. Yeah, that’s what we always preach– see something and create a “me-too” solution. Right?
Product management, like business management, is dynamic, open to change, should focus on people etc. Those companies that are static, put process ahead of progress etc. quickly die off.
So, here’s the original piece from October 2008. It was originally titled “Is Product Management Agile?” but I decided the new title was a better fit for the reprise.
There’s a lot of talk about Agile Product Management these days, and for obvious reasons. The thinking is that because of Agile development, Product Managers need to change how they function and adapt themselves to a new way of developing software and become “agile”.
But the reality is, Product Managers have always been agile, and finally the software developers are coming around to OUR way of thinking!
Yes, you read that right. Agile is the result of engineers finally understanding what’s really important and making a bold declaration that they now understand. But of course, being engineers, they won’t give credit to Product Management. They’re taking all the credit themselves for this tremendous insight and seachange in their profession. 🙂
Don’t believe me? I’ll prove that Product Management has always been “agile” using the Agile Manifesto itself.
The Manifesto has 4 elements. They are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
OK. Let’s take one at a time and apply them to Product Management.
Individuals and interactions over processes and tools
Most product management teams are understaffed. In fact, in many companies you’ll only find individual product managers working alone with teams of developers. They have no choice but to interact face-to-face. And not just with Development, but with every other group in the company and many parties outside of the company.
“Hub of the wheel”? You know what that translates to in the real world? Meetings, and lots of them, with the primary objective to keep all teams aligned and aware of progress, status and plans. Those cross-team meetings aren’t for the benefit of Product Management!
As for processes and tools…well, most PMs will tell you they do what it takes to get the job done, and the only tools they have are usually email, Excel, PowerPoint and Word, possibly some crappy (free) wiki software and Post-it notes. No fancy (or even basic) requirements management tools for most Product Managers. Individuals and interactions: Yes. Processes and tools: Not much. Score: 1 for 1!
Working software over comprehensive documentation
What PM doesn’t want working software? If only the final product that came out of Dev and QA was guaranteed to always work as expected. PMs want working software so much they perform QA, file bugs, run beta programs and hound the testing teams to ensure all the important use cases actually work.
How many times have we taken a pre-release build and found that it doesn’t install properly, or fails when upgrading from a previous version, or has licensing problems or runs really slowly using real world data sets. Ensuring working software gets out the door is top of mind for every PM, and even though helping QA the product is not technically part of our job, many of us do it anyway to raise the probability of actually delivering working software.
Regarding comprehensive documentation, we don’t tell Dev teams to create 50 page spec documents. They choose to write them and then PMs are forced to sit through endless “spec review” meetings to ensure Dev has taken the requirements and translated them properly into something THEY understand.
As for creating comprehensive documentation, PMs can never be accused of that. What’s the most common complaint from Engineering about Product Management? Answer: “The requirements aren’t detailed enough.” ‘Nuff said. Score: 2 for 2!
Customer collaboration over contract negotiation
Too easy. Really, do I have to explain this one? OK, I will. “Product Management: Voice of the Customer”. How often have you heard that phrase? Meaningful phrase or not, Product Management focuses extensively on customer insight and collaboration. It’s another core aspect of the job.
But, there are countless true stories of Engineering VPs who exhibited disdain for what customers actually want or need. These people are so smart they know what customers need, with little if any input from the customers themselves. Case in point.
A survey of 500 customers showed clear priorities for a number of big ticket items that needed to be added to a product. Capability <A> was ranked #15 by customers but was a pet project of the VP Eng. Capability <B> was ranked #2 by customers. We only had the resources to do one of those 2 items, along with everything else that was planned.
PM: We’ve laid out the requirements in priority order. < B> is critical for the next release and given the target release date, resources and survey results, we’ve deprioritized <A>.
VP: Hold it a minute. Are you saying that <A> is not important?
PM: Well, it’s not as important as <B> and the other things we’ve prioritized for this release.
VP: I was talking to MegaBankCorp last week, and they really emphasized the need for <A>.
PM: Yes, I spoke to them too. But they’re one of only 3 companies who have indicated they have an urgent need for <A>. I’ve got 50 companies that need <B>. <B> is more important than <A>.
VP: I don’t think you’re talking to the right people. I hear people asking for <A> all the time. Our major competitor has <A>, and we’ve lost deals to them.
PM: We’ve lost 1 deal to them on <A>, The sales team agrees that <B> is much higher priority than <A>, and the 500 hundred customers I surveyed agree as well.
VP: Don’t you realize <A> is strategic? Don’t you even read the industry news? You know what the problem with Product Management is?
PM: I’m sure you’re going to tell me.
VP: You talk to too many customers! You don’t talk to enough people who don’t use our product.
PM: People who don’t use our product also don’t tell us what they want added to the product. But, if you have the resources to do both <A> and <B> in this release, then be my guest. But <B> is top priority if you can’t do both.
Result: VP storms out of the meeting. Sends and email the next day indicating that after analyzing the effort and resources, both are not possible in the coming release so only <B> can be done.
Of course, not all Dev leads and VPs are as stubborn. But when it comes to wanting to work with customers, as opposed to sitting in meetings trying to get Engineering to buy-in on what is needed, Product Managers have always advocated for that. Score: 3 for 3!
Responding to change over following a plan
Next to “The requirements aren’t detailed enough“, the most common complaint that Engineers have of Product Management is that PMs regularly “change their mind“. Most PMs don’t simply change their mind about things, but reprioritize what is important based on new data, new market conditions, new company objectives, or other external changes that take place. That’s core to the role of Product Management. The world is a dynamic place, and when your competitor is bought out by and industry giant, or you find that you’re losing deals because of product gaps, action must be taken.
Yes, there are some flaky PMs who don’t have a clue about things, but that can’t be helped. Most capable PMs are reasonable people who need to focus on the business and leverage the engineering resources to help drive business benefit. It’s hard enough to predict what will happen 3 months from now, let alone 12 months from now.
But if a development cycle will take 12 months to complete, Product Management must be collecting the data to define that release many months in advance. Hey, we’re smart, but we’re not the Oracle of Delphi. We make decisions. Decisions are based on the information we have today. If something material happens after a decision is made that requires a change in product plans, the change must be made. Product Management always understood that. Engineering seems to be finally realizing that. Score: 4 for 4!
So there you have it. QED — quod erat demonstrandum.
Product Managers have been living, breathing and advocating the elements of the Agile Manifesto for years before the Manifesto was even a firing synapse in the brains of any of it’s authors. Developers though were set in their ways, with an “engineering” mindset, pushing back on Product Management for changing priorities, not providing enough detail in requirements etc.
I’m glad, even if they don’t want to admit it publicly, that Engineers are finally seeing the light. Now, if we could only get Management to allocate more headcount to Product Management, life would almost be perfect.
Tweet this: Product Management has always been “Agile” – http://wp.me/pXBON-3cA #prodmgmt #agile
By Saeed Khan
At ProductCamp Austin, someone, and I apologize, as I don’t remember his name, came up to me and asked me the following.
I really want to become a Product Manager. How can I make that move?
I wrote about this a while back in Open Question: How did you get your first Product Management or Product Marketing job?. Some readers also gave their experiences. But taking a step back, there’s a more fundamental question here.
How do you enter a field, where there is no singular definition of the role, no standard preparatory courses, and few defined hard skills to measure against????
Other fields are not as bad as Product Management.
Sales gets 2 out of 3 (i.e. there is a singular definition of the role, and a very clear measure of success (sales generated), but few if any standard courses).
Marketing get 2 out of 3 (singular definition and standard prep courses – yes, hard skills — not so clear)
Engineering gets 3 out of 3 (clearly defined, standard prep courses, and well understood and measurable hard skills).
I’ve actually never thought about it this way before, but now that I have I can more clearly see the issue for people wanting to move into the field.
For an outsider, it’s really unclear how to make the transition. So here’s my first attempt to put some structure on this task.
What do they mean by “Product Manager”?
One thing to keep in mind is that because there isn’t a commonly understood definition of Product Management, some companies say they want a Product Manager, but really want something else.
e.g. a Project Manager, an “Agile” Product Manager (e.g. you’re sitting with Engineers all day), a Business Strategist (this is Microsoft’s view), or a superhero who does everything (which is what a lot of startups want).
So first, get a clear understanding of what they actually want when they say they want a Product Manager.
What do YOU mean by “Product Manager”?
Within a mature Product Management organization, you should find a number of different roles. If not, but it’s a large organization, then it’s not really that mature. These roles can include Product Manager, Technical Product Manager, Product Marketing Manager, Solution Specialist, Analyst etc.
Think about what kind of role in Product Management fits best with your background and skills and pursue that type of role. e.g. If you are a much better communicator than technologist, then Product Marketing may be a better fit.
Qualities of Product Managers
In my Open Question, I did indicate that the following were important skills for Product Managers, though not necessarily in this order:
- Domain experience
- Communication skills
- Decision making ability
- Business understanding
There are other skills that are useful as well, though some are harder to measure than others. Technical knowledge is definitely useful. Empathy is also important. Judgement (related to but not the same as decision making) is another. Negotiation skills and sales skills are two more.
Match your skills with an appropriate role
But the question really is, what does a hiring manager need to see if they decide to hire someone with no formal Product Management (or Product Marketing) experience into that role?
Want to know the answer? Put yourself in the hiring manager’s shoes. What would you look for? And how could you position yourself?
Look at the table below. I’ve listed out a number of different roles who I’ve seen move into Product Management (there are of course many others not listed), and the TYPICAL strengths of people in those roles. (Your mileage will definitely vary).
(click image to enlarge)
Now, see if your skills are similar to those shown, or whether you are stronger (or weaker) in areas. For example, a QA Tester maybe a good fit as a Technical Product Manager, but without stronger domain experience (e.g. market/customer/competitor understanding) and stronger business skills, they may not be a good fit as a Product Manager.
Just to be clear, this table is provided as a high-level reference to give an additional level of clarity to different roles in Product Management departments. It’s not meant to pigeon-hole anyone or any roles. And as mentioned before, there are many other roles people have that could lead them to Product Management. For example, I’ve met former Sales people who became Product Managers.
So, if you are thinking about moving into Product Management, think about your skills and background, but also about what kind of Product Management role is a best fit for you. While this won’t guarantee you a job in Product Management, it may help you narrow down your search and help you leverage your strengths and minimize any gaps that hiring managers may use to disqualify you for a certain role.
Let me know what you think.
Tweet this: How to move into Product Management http://wp.me/pXBON-3cj #prodmgmt #career #prodmktg
NOTE: The following is a guest post by William King. If you want to submit your own guest post, click here for more information.
Is your profit margin thinning out? Is intense competition the biggest challenge for your survival? Is the ongoing economic downturn troubling your business? If the answer to all of the above mentioned questions is yes, your business might be drying up.
Rather than letting it wither, you need to take action at the right time to keep it fresh and alive. If your business is not doing well, there must be some ways to keep it running.
Just as oil is important to keep machinery running, engagement of new clients is important in keeping any business fresh and prosperous. However, engaging prospects is no longer easy due to tight global business environment.
If you fail to plan then you plan to fail!
Globalization and the internet have increased competition and now local businesses have to compete with companies from all over the world to win more prospects. As a new year has started, it is the right time to plan your business activities for the next 12 months. Running a business without a clear plan to engage customers is akin to sailing a boat without rudders. The plan will bring focus to any customer acquisition and engagement activities.
Focus on creation, not competition!
The idea of copying or emulating competitor’s products and launching them with some value-added feature made sense a few years ago. But today, this won’t work for most businesses. And fighting price wars is an easy way to bring both you and your competitors to your needs. The best way to engage customers is to create a differentiated offering which leaves you with little or no competition. Look at this example of how a street food hot dog vendor created something different and had lineups to his cart.
Identify the profitability of the sales!
While engaging new clients, don’t forget that not every sale is profitable for you in the longer run. If some customers are saying goodbye to your business, do not let them go, as it is almost always less expensive to deal with an existing client than to find and keep a new one. If a customer has a problem, make your utmost effort to fix it in a timely and satisfactory way. They will remember this and will likely tell others about it. But some customers, are never happy and in the long run may end up costing you much more than they will ever give. Don’t simply cut them off, but be careful when addressing customer issues to ensure you focus more on those who are likely to have some profit potential in the future.
A helpful attitude is the right attitude!
Though people claim to giveaway free samples and even offer rock bottom prices to win more clients, showing people that you care about their needs is even more important. Even those clients who are difficult to reach can be engaged with the proper attitude and intention. Show them how you can address what is important to them and how your product or service can help them achieve their goals. In the end, if you listen to them, they may turn from a difficult customer to a real evangelist for you. And that’s the ultimate goal when engaging with customers.
William King is the director of Wholesale Suppliers Directory and Wholesale Jackets. Being an entrepreneur and a passionate blogger he loves to share his knowledge and expertise with the industry by writing for various related blogs.