Category Archives: Guest Blogger

How To Streamline Your Product Development Process

By Emily Hunter

Many businesses are sustained and driven by product development. From small businesses to multinational corporations, the creation of new products is vital to market survival, especially in a world where trends, likes, and dislikes appear to change on an almost daily basis. Because of the swiftly changing market, many businesses have looked for ways to make the standard development process a little faster, or at least a little smoother.

In standard product development, there are several stages in the process like idea generation, screening, commercialization, and so forth until the product is finally ready for launch. While this development process works well, and is still in use by a great many organizations, it doesn’t always foster quick change and a fast development cycle.

A Holistic Emphasis

Holistic processes, used by major companies in the United States and Japan, do not get rid of a company’s stages of development, but merge them. When the idea is born, for example, it might move through the development team before the screening team compares and contrasts it with new product-related ideas, but both ends work in conjunction with one another. Instead of moving through incremental stages, everyone simultaneously contributes until the product is done.

Today, when a product needs to be built before the next big thing comes along, flexibility is a must. Having more hands on deck during product development requires more trial and error than the standard linear method. However, it also necessitates more communication between departments, which fosters transparency and openness through every level in a company. Once everyone understands what the other departments do, they are far more likely to take advantage of cross-departmental collaboration, allowing the company as a whole to reap the benefits of teamwork.

A Little Push

As always, development begins with an idea. In many cases, it’s a very broad idea — one that requires limits to be stretched and tested. When ideas arise in big companies, they are usually generated and imposed from above, unlike small companies, which can think big and aim for something they’ve never tried before. The problem with “thinking big” is that big ideas are often daunting to execute in real life.

Naturally, the idea has to be feasible. It also has to have a time limit. It’s going to be challenging, so everyone involved will have to be pushed a little — by themselves, by management, by the other members of their team. Enforce deadlines, maintain high standards, and monitor the quality of work, but do so within reason. Too much pressure can destroy a team, but just the right amount can drive people to achieve accomplishments they never believed possible.

A Team of Their Own

Product development teams tend to be extremely independent. Basically, they are given a concept, and they build a design around that idea. If the people involved are qualified in their specializations, the project will gain a life of its own. If upper management is involved in starting this kind of team, they should remember that such an arrangement works better if they just stay out of it. Shifting already established parameters as the potential to destroy the entire process.

Over time, the team will develop its own personal goals in an effort to complete the task in the time allotted, often fostering a strong sense of unity through the shared task. In effect, management won’t have to move the goal posts because the team will do this on their own. With each victory inspiring them to further success, every challenge overcome will instigate another even more difficult challenge in a kind of snowball effect.

Streamline Appropriately

The process of streamlining product development is great for many companies, but it is not for everyone. A freeform creative process tends to involve a great deal of overtime. For instance, a team that is not willing to put in the extra creative hours to bring an idea to life would be better off with the standard, more stratified process. Likewise, the naturally unstable and flexible teamwork setting of a holistic development process is not conducive to a huge project involving hundreds of people.

Some companies are run by a single individual who basically invents the products on his or her own and then gives the specifications to a design team. In this cases, it’s best to simply design the product as ordered rather than trying to improve upon the design.

Dealing with Change

It’s not easy to do something different from the standard procedure, especially the “old way” is deeply engrained into a company’s routine practices. However, change is often necessary. A new streamlined product development process may feel a little strange at first, and it may seem like it’s not quite working, But every new process takes some getting used to. Whether it’s a new software program or new machinery, mastering an innovative new process typically produces fantastic results.

Emily Hunter has been writing about business topics for many years, and currently writes on behalf of the product development specialists at Pivot International. In her spare time, she cheers for Spirit of Atlanta, Carolina Crown and Phantom Regiment, creates her own sodas, and crushes tower defense games. Follow her on Twitter at @Emily2Zen.

How A Rusting Giant Can Act More Like A Startup

This is a Q&A with Trevor Owens, Founder of Javelin, by Adam L. Penenberg originally published on PandoDaily, and re-printed here with Trevor’s permission.

Why should big companies emulate startups?

Back in the day, everyone wanted to work at a place like IBM. Today corporations are viewed as stodgy. Many of us don’t know what they do anymore and even if we did, we probably wouldn’t care. These bloated companies with their thousands of workers trapped within walls of bureaucracies aren’t growing anymore. In fact, their markets are shrinking.

The time between the birth, growth, and death of a large enterprise has shrunk dramatically over the years. Of the companies listed on the Fortune 500 in 1955, nearly 87 percent of them have either gone bankrupt, merged, reverted to private ownership, or lost enough gross revenue to be delisted. A study of the S&P 500, which ranks companies by market cap, found the average age of a business on the list was 61 years in 1958 but only 18 years in 2012. In the past, being big was in itself a defensible position. Now it’s not.

Contrast that with the frenetic growth and buzz surrounding successful startups. Instagram employed just 12 people when it sold for $1 billion. Snapchat had about 30 people when Facebook offered to snatch it up $3 billion. Whatsapp employed 50 or 60 people when it sold for $19 billion.

Big companies see this, and feel the cultural pull away from them. They’re starved for growth. If they want to compete, they have to become more like startups. Otherwise they’re in jeopardy of disappearing all together.

Why do big companies have trouble innovating?

When a company gets big, bureaucracy is layered throughout. In some ways it’s a necessary part of growth. The reason it exists is so the company doesn’t fall apart. The more people you have working for you, the more you need to manage them to ensure they get the support they need to do their jobs. Then you have whole divisions that exist simply to produce and sell, and their heads aren’t interested in new ideas, products, or ways to do things that could interfere with their bottom line, because that’s how they’re judged and compensated.

Couple all that with the main goal of a company, which is to serve existing customers. That’s where the resources go. Corporations offer an environment of execution and maintenance but not innovation, and rely on good management to target their best customers and deliver better products. That’s fine when they’ve identified and mastered their markets, but they get disrupted when a new entrant comes along that can deliver a good enough product at much lower cost of higher convenience. New entrants target low-value customers then quickly climb the value chain with a better cost structure. Think Netflix versus Blockbuster or Napster invading the recording industry.

Part of issue is there’s no management philosophy built around how to innovate within a large enterprise. With new companies we have the Lean Startup Method, which offers a framework for constantly improving a product to find the best product-market fit before you actually go into production or invest gobs of money in creating any infrastructure. This is the first time we’ve had a repeatable process. But there is no analog for large companies. They have to develop some basic structures just to deploy lean startup methods.

How are some big companies innovating like startups?

There are two parts to innovating like a startup. One is generating a flow of high-quality (i.e. validated) ideas. We call this “innovation flow” — similar to the idea of deal flow for venture capitalists. If a VC doesn’t have good deal flow he won’t get returns.  The other is the need to create a structure to incubate these ideas called an “innovation colony.”

Intuit does the first part well. It kind of copied our lean startup workshop and scaled it throughout the company. After employees have been trained in lean startup methods and know how to validate ideas, they can take advantage of unstructured time (also known as 10 percent time) to work on any project they want to validate that can potentially become a successful new product. If they find they have something they can go to their boss for funding, and this has led to some viable products, including Sparkrent.

Facebook is famous for hackathons. That’s where the Timeline was first imagined. Employees can work on anything that relates to the company’s products and deliver a down-and-dirty prototype during a 24-hour hackathon. Companies like Nordstrom are becoming sophisticated at lean startup methods. It runs weeklong experiments. One from 2011 involved an iPad app that helps users choose eyeglass frames and another addressed the physical design of its retail stores.

Companies also acquire startups to “buy growth,” although few buy at the right time. One that did was Twitter, which acquired Vine before it launched, left it alone to carry on its mission without interference, and it ended up a great acquisition. Vine clearly had product/market fit right out of the gate.

What about skunkworks, innovation labs, and intrapreneur programs?

For large companies there are three traditional innovation structures:

First, there’s skunkworks, when you hire a bunch of smart people to work on pie-in-the-sky technologies. Motorola, for example, hired away a former head of DARPA to run its skunkworks. It only works on highly technical products with low market risk — like a faster jet plane or Amazon Web Services. It’s not good for developing, say, an app like The Daily and it won’t help you find a market or determine product-market fit.

Then there are innovation labs. Perhaps the best known was Xerox Parc, which was the original Innovation Lab. It came up with brilliant ideas but failed to commercialize them — until Steve Jobs came along and borrowed (some say stole) them. Innovation labs that focus on innovative technologies are known to struggle with commercialization.

Finally, you have intrapreneur programs, which are the latest fad: a four- or eight-week program where employees take time off, explore some ideas and a product, and have to sell it to a business unit within the company.  The issue comes back to the incentives inherent in successful business units. They resist ideas they didn’t come up with, no matter how big their potential. They favor incremental innovation that won’t cannibalize their own sales over something that could change their industry for the better.

As a corollary you can have something we recommend: innovation colonies. This is a way for companies to create a fund to invest in ideas their employees have. To participate, though, the employee has to give up the security of their jobs in exchange for equity in the venture. Microsoft, Kaplan, Nike, Barclays, and Disney are just some of the companies utilizing innovation colonies.

Here’s how they work: Employees pitch their ideas, which have been validated, get funding, and own a majority of the equity in these products in the seed stage. They work with other entrepreneurs and the company offers advisement, mentoring and other resources. They seek to develop products, take them to market, and if they gain any traction they can raise a series A with outside investors. They run the company without interference from the Mother ship. In the end, the big company can offer to buy their startups back. The magic is that the entrepreneurs are incentivized to build a real business.

Is it a good idea to offer equity stakes within corporate environments?

Oh, yes. In fact, we advocate for employees to get equity on their projects. Let me emphasize that I mean equity in the product, not the company. Equity attracts the best people because entrepreneurs are motivated by achievement and autonomy and are willing to take less in salary in exchange for more upside in their ideas. Of course, they want to see millions from their products, if they’re successful, but it’s not just about money; it’s what it represents. It’s about being recognized for your achievements. Face it: you have to be a little crazy to be an entrepreneur. This is the whole point of the innovation colony structure.

If you don’t give employees who are entrepreneurially minded equity in their projects they’ll leave to start their own companies. This happens even at innovation-friendly environments like Google: Ev Wiliams (Twitter), Kevin Systrom (Instagram), Dennis Crowley (Foursquare) all left to launch their own ventures. It’s unfortunate that Google doesn’t share in any of the billions they’ve created.

Not only do you want to hire the best and brightest, you want them to stick around and create the kinds of innovative products and services that will also ensure your company sticks around for the long term. Some large companies make the mistake of addressing a problem by simply throwing 15 developers at a problem thinking it will lead to something. Instead, great ideas come from all over an organization and may even seem like bad ideas at first until you validate them.

Once a company realizes this, anything is possible.

Trevor Owens is a thought leader on Lean Startup. He is the Founder of Javelin, a provider of tools and services to learn, launch and track new business ideas, and Lean Startup Machine, a three-day workshop that teaches entrepreneurs and innovators how to build startup products. He has a new book called The Lean Enterprise that talks about how to bring the startup mindset to larger organizations.

Yes, Startup Products Can Take A Village

Thomas Pichon is the Founder of The Collaborative Startup. He advocates building a community to gain traction for a startup, and I thought the advice could equally apply to an “internal” startup. The article below is re-posted with his permission from his free e-course.

By Thomas Pichon

I am helping an entrepreneur build a yoga retreat, and I asked her how she was going to build her project. She said:

“I guess I’m going to concretely build the service, which means finding where we’re going to host the retreat, build the program, etc… Then, I’ll try to advertise it.”

I used to build products with this kind of strategy for years. Results have never been extraordinary. However, I have discovered one which brought me much more success:

  1. Build your community. Share helpful content related to the service you want to provide in order to attract people.
  2. Ask them what is their biggest frustration. Build a service around this problem.
  3. Get pre-orders. Start collecting credit card numbers before you have built the service. If you have created trust with your community by providing helpful content from day 1, you will see that this step is much easier than it looks now.

Hope these lines help you understand how to start your business. Do not build your product, then try to sell it. Sell it, then build it. And the better way to sell it before having the product ready is by building trust within a community.

So start now! Write helpful content about your topic in order to start building trust! Share it where your target audience hangs out online.

If you need any advice on this topic, or more generally about startups, you can schedule a call with me anytime, or ask your questions on my forum.

Thomas Pichon is the Founder of The Collaborative Startup, an innovative initiative designed to help entrepreneurs by leveraging the power of community development, Lean Startup and crowdsourcing.

The Dirty Dozen Product Roadmap Roadblocks

In my last post on defining an MVP in corporate innovation, I talked about how best practices in garnering stakeholder buy-in for product roadmaps espoused by Bruce McCarthy can be used as a framework for the same when defining an MVP in an “internal” startup product. Here, with permission, is a re-post of his excellent post on the the “Dirty Dozen” product roadmap roadblocks, and in a way, they seem applicable to internal startup products as well.

By Bruce McCarthy

A good product roadmap is one of the most important and influential documents an organization can develop, publish and continuously update. It’s the one document that steers the entire organization in delivering on the company strategy.

It’s key to success, and yet many organizations struggle to produce effective roadmaps. In fact, many organizations don’t create one, even to publish internally. Or they do, but it is simply a collection of unrelated features and dates.

What Is A Product Roadmap?

A roadmap is your vision for how a product (or product line) will help achieve your organization’s strategic goals. In that sense, it is literally a map of the steps involved in getting your business where you want it to go. To make it even more concrete, I also like to think of a product roadmap as a timeline view of your priorities.

A good roadmap inspires. It inspires buy-in from executives, inspires confidence from customers and salespeople, and inspires development teams to produce the groundbreaking products that drive significant growth.

A good roadmap keeps your organization on course toward its destination. Stating what you will do and when makes it easy to judge when you fall behind schedule or get detoured by good ideas that just don’t fit your strategic vision.

The Dirty Dozen

In my experience, though, there are some specific areas where companies commonly break down in developing roadmaps, hitting roadblocks that often keep them from getting where they want to go. I call these roadmap roadblocks the “Dirty Dozen.”

1. No Strategic Goals

If a roadmap is the path toward your goals, you obviously need to set those goals before you start. Yet many companies fail to sit down and explicitly describe the destination they are driving toward.

Is your product roadmap aligned with your strategic goals? Have a conversation with your CEO or another exec in the know. It may clarify a lot of your prioritization dilemmas.

2. Focusing on Features

A lot of roadmaps are just a list of features in upcoming releases. This is meaningless to most people outside of the development team. A roadmap should make it obvious how things will improve for your customers, organization or shareholders. Like any good sales pitch, it should focus on delivering value.

Look at your roadmap from the point of view of a board member or a customer. Would they see their interests reflected?

3. Inside-Out Thinking

Focusing on features can be a symptom of failing to understand your market. Yes, priorities should be driven by internal goals, but those goals must also respond to market reality.

Ask yourself whether your roadmap priorities are driven by the needs of the people and organizations you intend to serve. Strive to bring that message from the outside in.

4. One Size Fits All

You probably serve more than one market segment. When you are talking to customers or partners in one segment, the roadmap you show should focus on how you will address their needs.

Make sure your roadmap is not one-size-fits-all. If a customer sees their interests in only 1 of the next 6 releases, they’ll get the message that you are not focused on them.

5. Trying Too Hard to Please

That said, many roadmaps are simply lists of customer requests prioritized by number (or size) of customers requesting or voting for the feature. This may help with retention for a while, but will not drive your company into new markets or to invent anything new.

Rather than just taking requests, listening for unsolved problems in your market (and doing something about them) is the best way to avoid a roadmap that’s really just a popularity contest.

6. Playing Catch-up

It’s often a mistake to focus on matching your competition feature-for-feature. All this does is commoditize your market. Instead, focus on creating unique value by developing solutions your competition can’t easily duplicate.

How many items on your roadmap are “me too” features designed to close perceived competitive gaps? How many of those have actually lost you business?

7. Not Getting Buy-in

The best-conceived roadmap won’t get you where you need to go if you can’t get anyone else to come along for the ride. You’ve got to get your development, sales, marketing, finance and other stakeholders involved early so it becomes their plan, not just yours.

If people use words like “intellectual,” “cerebral,” “theoretical,” or “ivory tower” to describe you or your work, this is code for lack of buy-in.

8. Prioritizing on Instinct

Good product people develop good instincts for their market. As a company grows, though, it’s hard to get the buy-in you need from all players based just on your instincts.

Can you tie everything on your roadmap back to your strategic goals? Can you show the ROI calculations that put priority 1 ahead of priority 2? A little data settles a lot of arguments.

9. Being Too Agile

Agile was developed as a response to lack of consistent direction from business execs. That doesn’t mean it’s incompatible with good direction. Yet many companies fear to map out a course thinking it’s not allowed in Agile.

Don’t let being agile become an excuse for indecision. You may choose to adjust course down the road, but you’ll move a lot faster if you first take your best guess at a destination.

10. Being Too Secretive

Some organizations have a roadmap but shy away from sharing it with anyone. It might be fear of revenue recognition issues, lack of confidence in the company’s direction, or just not wanting to look foolish if things change.

A good roadmap is not a contract. It can and should be designed as a statement of direction and intent, but customers and investors expect you to accept and act on feedback from the market. They expect your roadmap to change, so stop worrying.

11. No Buffer

One reason an organization might be reluctant to share is if their roadmap is too detailed. A roadmap consisting of 40 bulleted features in each of 10 precisely-dated releases is impossible to read, and can really constrain your options for adjusting course down the road.

Your roadmap should consist of problem-solving themes and broad time-frames. This gives you the leeway to cut or defer a specific feature without risking on-time arrival at your destination.

12. Over- or Underestimating

ROI is a critical consideration in prioritization, yet many product teams make the mistake of setting business priorities without considering development costs. Conversely, some teams spend months estimating every possible product initiative without first considering which are likely to be worth the time.

Approach your technical partner for a quick, high-level estimate of the work involved in your 10 most wanted. What if #4 turns out to be trivially easy compared to the 3 ahead of it? Wouldn’t you like to know that up front?

AN INVITATION

If your organization’s progress toward its strategic goals is slowed by any of these roadmap roadblocks, feel free to set up a time to chat with me during my free office hours. You may also be interested my hugely popular roadmapping presentation from ProductCamp Boston, or in Reqqsthe smart roadmap tool for product people.

Use your product powers for good.

Bruce McCarthy is a serial entrepreneur, 20-year product person, and sought-after speaker on roadmapping and prioritization. He is Founder and Chief Product Person for UpUp Labs, where he and his team are at work on Reqqs, the smart roadmap tool for product people.

Original article can be found here.

How I Became A Product Manager

By Tony Lizza

My God, I’m going to die here, I thought. Every morning the melodrama played out as I marched into the support department of the company where I worked. I had started out there a couple of years before, and everything was easy and fun. I was learning new things. Two years on, I was burned out. No more learning, no more excitement. Just ringing phones, and angry customers, and impossible deadlines, and my god, I’m going to die here. I didn’t see myself in support for the rest of my career. I found quality assurance and documentation tasks dull, and I knew I didn’t want to keep track of project spreadsheets for the rest of my career, so implementation was out. I was always drawn to the process of creating something new, but I wasn’t an engineer. I felt hosed.

All wasn’t lost, though. Even though I didn’t have a technical degree, I accumulated a lot of technical knowledge. I was able to go to work in the documentation department where I got to work writing training material and use cases for features of a new software product. About a year after that, I took a position in the product department of my company. Here’s what I did that helped me.

1) I was curious

I learned about as much as I could in each of my roles. Product, market, domain, it didn’t matter. My first job was supporting a legacy receivables management software package. In addition to soft skills, I used that opportunity to learn Linux, Bash scripting, and Python, among other skills. Have they all been equally useful in career as a product manager? Not all of them, I admit, but some certainly did.

2) I was helpful

I did everything I could. If the website needed updated copy, I volunteered to write it. If an RFP came in, I volunteered to help with it. I did anything to build my knowledge of the product and the market. As a character in Mad Men said, “This is America. Pick a job and become the person that does it.” But be willing to start small. Approach the product manager or department head, and say that you’re interested in taking on some product work. This might be tough if you’re not a natural gladhander. (I’m certainly not!) But most people are willing to help those who ask for it, and there are plenty of long suffering product departments that would be bowled over by your interest. These things often live and die on the say so of your current supervisor, so make sure he/she approves it first. If your company releases a product, SOMEONE is doing product work, or at least should be. If there’s not a formal department, so much the better. This means that somebody has been taking on product work in addition to his/her own workload, and would probably be glad to give some of it up.

3) I positioned the experience I had

I leveraged my experience in those areas to get into a product management role as a BA. It’s about positioning. If you worked in support, then you have customer empathy. If you were an engineer, then you can speak intelligently about product timelines and feature priorities. If you were in sales, then you know the market and have experience qualifying customers.

Even though I didn’t do this, it helps to get a mentor, either someone at your company, or volunteer with an organization like ProductCamp DC. Communities of interest like these are full of passionate, knowledgeable people who genuinely enjoy helping others. (Full disclosure: I am a volunteer with ProductCamp DC.)

There are plenty of other skills that product managers need. E.g., how to build consensus within an organization, how to interview customers, how to develop a product roadmap, etc. But at the very, very beginning, it came down to those three for me. Not coincidentally, these qualities not only helped me get a product management role, but also have served me well as a product manager. And every day I am learning. And every day I’m excited.

Tony

Tony Lizza is a Product Manager at AARP. He tweets at @tonylizza.

Why Product Managers Need To Get Out Of The Office

By Kevin Dewalt

For the past few months I’ve been doing Customer Development on product managers to explore their viability as a customer segment for my new startup, sohelpful.me. I’ve been asking them about their challenges in getting insight to customer problems. I haven’t had a job as a product manager in over 15 years, but if you’ll forgive my naivety, I would like to offer a few observations on how the role of product managers has to change, at least if their employers want to survive the coming onslaught of worldwide competition from startups.

The Best Product Managers are Learning from Entrepreneurs

The management science of entrepreneurship has changed more in the past 5 years than in the previous 500. Through Eric Ries’ Lean Startup movement and best practices like Steve Blank’s Customer Development, we are finally seeing the emergence of repeatable patterns and best practices for mitigating the risks of product failure. Prescient product managers — often former entrepreneurs themselves — are seeing these best practices emerge and looking for ways to bring them into their own organization. Unfortunately, many are describing practical challenges with getting their employers to embrace this change.

No Established Processes for Connecting Product Managers & Customers

Unlike entrepreneurs, product managers are beholden to an organization’s behavior, rules, and roles. These structures often create practical barriers between product managers and the very tedious process of developing problem-solution assumptions and testing them with customers.

Customer Input Filtered by Other Stakeholders

Many are frustrated with what they describe as filtered customer input — often by sales or marketing teams who are focused on the most recent customer conversation. They recognize the importance of this feedback,  but feel that it needs to be considered in a larger strategic context.

Overwhelmed with “Inside the Office”

Product managers tend to be multi-skilled, dynamic people — those who are already overwhelmed trying to get an organization to execute. Many describe themselves as spending way too much time focused on day-to-day fires or “project management”.

Your Employers Need to Wake Up: The World Wants Your Customers!

Forget Silicon Valley. Through my free startup help sessions, I’m giving advice to entrepreneurs worldwide – Beijing, Bangalore, Singapore and Manila. They’re often 3-5 person teams trying to build highly customized solutions to micro-segments of your customer base — for a lot less. At least 50% of my discussions are about doing Customer Development on the American market. Their biggest challenge is “getting out of the office” — talking to customers to get insights. They’ve read Ash Maury’s Running LeanEric Ries’ The Lean StartupJeff Gothelf’s Lean UX, and watched Steve Blank’s (free) Udacity CourseI try to help them find your customers to get better insight using lower-cost techniques like recruiting them over Craigslist for problem-solution interviews. For the moment, your employer has some practical advantages over these new competitors – language, time zone, trust, experience, and relationships. In the long run it won’t be enough if your employers don’t wake up to the reality that your job has to change. But, alas, they probably won’t change. Most likely you’ll realize it before they do, but by that time you’ll already be gone — you”ll be “getting out of the office” building your products in your startup. Perhaps after they acquire your startup — for 1,000x your salary — they’ll listen.

Kevin

Kevin Dewalt is an American entrepreneur & investor currently living in Beijing, China. He writes about his experiences building products at his blog and on Twitter.

3 Things Product Managers Can Learn from Management Consultants

By Alex Joseph

 

House Of LiesManagement Consultants are probably one of the most ridiculed professionals in popular culture (only next to Wall Street bankers). They are often portrayed as ruthless and self-obsessed mercenaries in Dilbert cartoons (‘Dogburt, the Consultant’) or in ‘House of Lies’, a show which is based on the book titled ‘How Management Consultants Steal Your Watch and Then Tell You the Time’!

However, most executives admire management consultants (at least secretly!) and would love to hire top-notch consultants. After having worked as a management consultant and a product manager, I have noticed that many product managers are still skeptical of ‘the consultants’, as most PMs come from engineering or design. I understand some of the concerns, but also believe that many consulting skills (apart from the passion and drive) can be extremely valuable in product management roles. Here are three of them. (BTW, according to consultants, any list should only have three items, since people can’t remember more than three things!)

Gather Data Smartly

Good management consultants are extremely analytical and are obsessed with data. Though sometimes bordering on ‘analysis paralysis’, consultants are methodical in proving or disproving their ‘hypotheses’ and often find creative ways to find proxy data, when it’s not easily available. Though often derided as ‘POOMA’ (you know what that means!), estimating something hard to observe based on something you can observe can be extremely valuable in product management, since the most interesting market data is rarely presented cleanly in an analyst report!

In my first consulting project, the engagement manager asked me (as the most junior member of the team) to analyze the success stories of the four biggest competitors. It was a painful task going through 100+ customer testimonials, but when I clustered them into industries creating a heat map (in one chart), it was an eye-popping revelation how few use cases they actually address – despite their public claims of solving every problem under the sun. It was a classic case of ’80-20’ (as consultants would call it). The conclusions were not entirely surprising, but we then had solid data to back that up, instead of getting into the ‘my opinion vs. yours’ religious battles.

Synthesize and Present Top-Down

Product managers sometimes get lost in a ton of data. I recently watched a product manager presenting a proposal using many dense data charts – pulled from various analysts segmenting the market in different ways and presenting numerous possible features and functions. At the end of the long presentation, I asked him, “Where should we focus?” His answer was, “They are all attractive, and if we have the resources we should do them all.” Something a good management consultant would never say!

In consulting, the ability to structure the message using the Pyramid Principle is extremely important. The goal is to communicate top-down with the most important message first (‘tip of the pyramid’). The supporting conclusions are presented at the next level (following ‘MECE’), resembling a pyramid. This makes it easier for the reader (and especially for busy executives) to grasp the gist of the message instead of being bombarded with a lot of rambling details.

While telling the story, most use a variation of an approach called Situation, Complication, & Resolution to drive to a clear course of action. All of these are equally important for product managers while communicating a product vision & strategy. (Good presentation on applying Pyramid Principle for structured communication).

Gallery of management consultants

Get Stakeholder Buy-In

One thing in common between consultants and product managers is that they often have to ‘influence without authority’. It’s critical for consultants to get buy-in from executives by finding common ground. Most construct a stakeholder diagram at the beginning of the project to figure out the key people to influence. Contrary to stereotypes, no smart consultant will walk in to the big meeting with a heavy PowerPoint deck without getting buy-in privately from these decision makers (‘pre-wiring’).

Product Managers (especially in a big company) have to navigate complex organizational units. Many PMs, especially those from a technical background, seem to have the naïve belief that ‘the best idea will win’. ‘Politics’ may sound like a dirty word, but it’s nothing more than using emotional intelligence while dealing with organizations and executives (that are human too!), considering their collective self-interests.

Does this mean that all management consultants would become excellent product managers? Not always, but that’s a topic for another post.

Alex Joseph is a product manager and former strategy consultant and engineer. He is now an ‘intrapreneur’ in a large software company in Silicon Valley applying what he has learned from startups and corporates. Alex reflects on consumerizing the enterprise by beautiful mobile apps on Twitter and his blog.

Guidelines For Conducting A Customer Conversation Session

By Prashanth Padmanabhan

There are some basic principles that you can follow while telling your story to your customer.

1. Show up at the customer’s office, if you can.

It shows respect. It tells them that you care for their thought. It is money well spent. As a product manager or product designer you are the voice of the customer and that is your only advantage over every other function. So customer visits should be your number one priority. Nothing else is more important than that.

2. Always show a prototype or draw a picture on the white board.

Don’t show a set of slides. This forces participants to think differently, look at the prototype and imagine rather than go into a passive finger-pointing mode. The prototype must include a list of concepts that you want to confront them with for feedback. Organize those concepts in the form of a story you can tell by going through the different screens in the prototype. Pause for a few seconds after each concept is outlined and let the interviewees share their thoughts. Acknowledge any interesting thoughts that come up and move on to the next concept in the story.

3. After introductions, ask them what they plan to get out of the session, and write that down on a flip chart.

If the crowd is large, ask everyone they plan to participate or if they are merely there to observe. Differentiate between the participants and observers and direct the conversation to the participants.

4. Listen more. Speak less.

You should be talking for about ten percent of the time and listening for the reminder of the time. If you have a hard time keeping quiet, take on the role of the writer on the flip chart. This will help you talk less and listen more. It will force you to keep quiet and will nudge customers to think aloud and direct you writing.

5. Write or draw on a flip chart.

Don’t sit down in a chair and write in a notebook where no one can see what you are writing. Writing on a flip chart, conveys to customers that you are listening, synthesizing and are open for comments. They can see your thought process, point out gaps in your thinking and, if necessary, correct what you write. So take notes publicly. Not privately.

Tip: Avoid total silence when in a conference! If you are running a workshop via conference, while taking notes, please avoid silence. Tell the customer you’re taking notes so they know you are listening.

6. Display all the flips charts all the time.

Do not flip the chart over and go to a new page. Tear the paper you wrote on and tape it to a wall. Don’t worry. Customers do not mind you posting 4-5 flip charts on the walls of their conference rooms. Pausing to tape the flip chart paper on the wall will give you a logical break after about 15-20 minutes of conversation. If your colleagues are present, it will give them an opportunity to chime in. It will also give you a minute to collect your thoughts.

After your paste the flip chart on the wall, underline the key words in the notes, recap the conversation, point out who said what, and ask participants if you missed anything. It gives participants an opportunity to point of simple errors that are bothering them.

7. Document while at the session.

Not after you come back to the office. Use a (phone) camera to take a picture of all the flip board charts. That is you documentation. You don’t have to write elaborate notes after you come back from the session. Post the pictures to a collaboration site, such as Streamwork, SuccessFactors JAM, Yammer or SharePoint, along with the notes and share it with customers.

8. Capture customer quotes and share them with colleagues rather than writing elaborate reports. Your colleagues will appreciate the quotes from customers and users.

Prashanth Padmanabhan is an entrepreneur, product designer, collaboration enthusiast, product manager for people and work management software, and SAP mentor. He’s co-authored two books, SAP Enterprise Learning and Look & Flow, a book on product innovation using design thinking and storytelling. His blog is Journal on Product Design and Development.
This post was originally published on Look and Flow, the blog site for his book. It is reprinted here with permission.