Category Archives: Organization

10 Things To Do To Appear ‘Innovative’

Being “innovative” is all the rage nowadays. Companies big and small, tech and non-tech, are striving to seem innovative to employees and customers.

I’ve worked at such companies, and I’ve helped many product managers working at such companies through my product help calls. As such, I’ve seen companies that are actually trying to be innovative, and those that seem more interested in giving the appearance of being innovative.

So here are ten things a company can do to appear innovative than actually be innovative:

#10. Start using buzzwords, like “MVP”, “lean”, “experimentation”, “hypothesis” and “failing fast” without actually understanding what they mean or what they involve.

#9. Visit Silicon Valley a lot, and come back to share stories of t-shirt wearing founders and how everyone there uses Macs.

#8. Start sponsoring and hosting lots of local tech meetups.

#7. Change the office to look more “startupy”. Or better yet, build a brand new one with an open floor plan, sofas, “nap rooms”, and an Xbox.

#6. Offer lots of free food and unlimited sodas, and host “Pizza Tuesdays” and Wednesday afternoon NERF gun battles.

#5. Tell folks at company town halls that you’re embracing innovation. Just keep saying this. Over and over.

#4. Declare that “mobile is the future”.

#3. Enthusiastically share with employees the millions the company is spending to acquire hot tech startups and entrepreneurs (instead of investing in the existing employee talent).

#2. Declare “entrepreneurship” as a corporate strategy. Or better yet, start challenging employees to be more “entrepreneurial”. Make sure they put it in their professional development plans.

#1. Launch an innovation lab. It may not actually do anything real, but this must be done.

Do these 10 simple things and your company can look innovative too.

Introducing Product Management Into Your Company – Part 2

In my previous post, I talked about the challenges of introducing Product Management into an established organization. Here I share hard learned lessons on how to avoid common pitfalls and start laying the foundation for long-term success.

Start with why

If you’re looking to bring on product management into your organization, start with this simple, but fundamental question:

Why?

Seriously, why do you really need product management? What problem are you expecting it to solve? Innovation? Improved product development processes? Better requirements writing? Maintaining feature lists? Being the demo guy?

The ‘why’ question is critical, because it sets the expectation for the value Product Management is expected to bring to the organization. It also crystallizes whether there are ways to solve the problems the organization faces through its current structure. Perhaps the existing departments could take on various Product Management functions, or could be re-structured, and appropriate processes can be developed around them to ensure continuous innovation. If this is not possible, and centralized product focus is needed, then perhaps introducing Product Management does makes sense.

Tip: If you’re hiring a product manager because you’re developing a software and simply need someone to provide requirements to engineering and project manage delivery, don’t hire a product manager. Hire a project manager who can double up as a business systems analyst.

Prepare the organization

The fact is Product Management is a disruptive force, a radical change to the way the organization has been conducting its business thus far. The introduction of a product management function will centralize many functions that were previously diversified. (Fragmented?) Senior leadership must think carefully if this is something they want to take the organization through, and must prepare to shepherd each of the other departments through their change curves.

Who is your first hire? And where do they sit?

A more senior individual will bring the experience and know-how to take on a more leadership type role, quickly formulate the product strategy and develop a roadmap, and when the time comes leverage their personal network to bring in additional product management talent.

For a growing company, taking over many of the product strategy execution aspects off of the CEO, COO, etc. is exactly what the first formal Product Management leader would do. As such, you’ll be better off making your first hire at a more senior level, at least VP or Director. Ensuring sustainable success for the position — and, thus, for the product strategy — in an ideal manner means setting it up in terms of stature and position with respect to the other departments.

A common push back I hear from organizations that have never hired a product manager is they worry a more senior person may not be willing to be as “hands on” and handle the necessary tactical activities that need to be done. First, product management is a unique discipline that necessarily requires one to execute tactically while thinking strategically. Second, just make sure you hire the right person who can execute as tactically as you need.

Now, it’s possible the company may simply not have the budget to hire a senior level product management professional, since such a person will naturally command a higher compensation. And waiting to have the right budget may not be an option if the company is in crisis mode where it needs someone to step in to pick up activities that are getting dropped. So the company may be forced to opt for a more ‘junior’ product manager.

One of the biggest risks here is where to place this individual in the organization. I would still advocate having this person report directly to the senior most executive in charge of product strategy, including the CEO.

Unfortunately, what often happens is the individual is put into marketing, sales or engineering. The dangers with this approach are well documented.1 In effect, the product manager becomes a support role for the primary function of that department, providing content for marketing materials, doing product demos for sales, or writing requirements and project managing deliverables for engineering. No time to do the critical work of understanding market problems and formulating the product strategy.

Who to hire and where they sit are critical decisions to ensure long term success. I once worked for a company that rotated through five directors and seventeen product managers in just six years. A total of twenty two. Twenty two!

Ensure senior sponsorship

Ensure there is someone in a senior executive position who is willing to be the champion for Product Management. This has the greatest impact on Product Management’s long-term success. You need someone at that level to evangelize the value that product management brings to the organization, and provide the necessary air support when political attacks threaten to disrupt it in its formative stages.

Do you feel lucky? Well… do ya?

So far I’ve talked from the organization’s point of view. What if you’re the first product manager in the company? The Product Management Journal has some great tips on introducing Product Management into a startup. I expound on those to encompass any organization:

Clarify your role

Because expectations may vary widely, it’s important to clarify your role upfront. If you’re joining a startup, an enterprise with a visionary CEO, or a company with established lines of business, the CEO or line of business may want to continue to act as the product visionary and retain control over the product direction. In this case, Product Management may play a more tactical role, working more closely with engineering on product releases, perhaps supporting marketing and sales activities. Your role with respect to setting the product strategy is strictly as an influencer. You must ask yourself, are you cool with that? If not, the role is simply not a fit. Move on.

Clarify expectations

You need to have a mutually agreed upon definition of success, and clarify how your performance will be judged, and reconcile these with the scope of the role. If you’re expected to play a more tactical role, yet deliver product innovation, or if you’re measured on the number of defects and customer complaints, yet the role is about market insight and setting the product direction, these are signs of expectations being incongruous with the role. (In other words, bluntly, the role is set up for failure. My advice: run away.)

As stated earlier, Product Management is an agent of change, because it changes existing business processes, and takes decision making and responsibilities away from current owners. This creates uncertainty. To the extent reasonable, talk to everyone. Understand their expectations. Share these findings with your hiring bosses to clarify expectations and the role, and ensure they are congruous. Doing this has the added benefit of helping you establish key relationships and build your credibility. (Important!)

Ensure senior sponsorship

Same as discussed above, except now from the individual’s lens. Regardless of whether you are coming in with the title of VP or Product Manager, be sure there is a true believer at the senior executive level who will go to bat for you, give you the space to establish yourself into the role, and support your efforts to be targeted and focused.

Which brings us to:

Focus!

Look, you simply can’t do everything. If you’ve done your homework on the role and expectations fronts, identify what you think are the most pressing problems, share them with your stakeholders, gain their buy-in, and focus relentlessly on the top priorities. Lower level priorities and new problems will of course crop up, but at least you’ll either be able to fall back on the agreement you reached or have a constructive conversation on re-assessing priorities based on new realities. This gives you a much greater chance to get things done while keeping your credibility intact.

Introducing Product Management into an organization can be fraught with ambiguity, unreasonable expectations, and threats from every corner. But with foresight and planning, it’s possible to set it up for long term success. Either way, it’s going to be roller coaster. So saddle up, buckle in, and get ready for a wild ride!

1Further reading:
Marty Cagan: Where Should Product Management Live?
Steve Johnson: Where Does Product Management Belong In An Organization?
Rich Mironov: Where Should PM Report?

Introducing Product Management Into Your Company

This is part 1 of 2. Also published on OnProductManagement.net. Part 2 is Part 2 is here.

If you are considering introducing Product Management into your organization, or are the first Product Management employee hired into an established business, then tread carefully! Having done this more times than I care to recall, I can attest there are fewer professional situations more fraught with ambiguity, unreasonable expectations, threats from every corner, and high likelihood of failure for the Product Manager and the organization.

Why would a successful business decide to introduce Product Management into its organization at all? In one of the companies I had joined, the business had been extremely successful selling variations of essentially the same product for years and years. But with potential new business drying up, the execs decided the company needed to be more “innovative”, and their answer was to create a Product Management department. Other reasons could be:

  • With everyone in the company focused on marketing, selling, customer service, managing operations, hiring, and a hundred other things, the organization finds no one is focused on growing the product portfolio.
  • On the other hand, the product portfolio may have grown like wild fire, and now there are multiple versions of the product, causing customer confusion and inefficiencies within the organization. Time to consolidate.
  • The product has become so “feature rich” that sales and marketing no longer know how to position the product to customers, customers cannot be serviced efficiently, and delivery dates keep slipping as each additional piece of functionality adds exponential risk to development and testing.
  • A services company is trying to become a product-focused one, and after lots of wasted time and money realizes they need product management.

For any of these reasons, the company executives decide its time to bring in Product Management.

Buyer beware

Although these situations may seem ideal to introduce Product Management, they abound with pitfalls for the unaware. It’s important for both company execs and Product Management to be mindful of numerous land mines:

Unfounded unreasonably high expectations. Product Management is suddenly looked upon as the silver bullet answer to all the company’s problems.

Not all expectations are created equal. Expectations are also different across each department:

  • Engineering/IT expects Product Management to write requirements, ensure zero scope changes, project manage the delivery, conduct UAT, manage defect resolution, and make seamless release go/no go calls.
  • Sales expects Product Management to be available for every sales call, produce sales collateral, do product demos, commit to product features that will help them close the next big deal with a guarantee to have them all available by the date they already promised to the client.
  • Marketing expects Product Management to provide the content for marketing materials or, worse, wants nothing at all to do with Product Management.
  • Execs expect Product Management to come up with the “next big thing,” have a solid business case behind it, deliver it on time, and ensure it makes a ton of money.

What does Product Management do? Most times folks don’t understand the role of Product Management and the value it brings to the organization. Let’s see…

  • Salespeople close deals.
  • Marketing runs campaigns, advertising, promotions, and events.
  • Account management manages client relationships.
  • Operations manages business processes.
  • Customer service runs the call center.
  • IT takes care of “all that technical stuff” the rest of the organization would rather not be bothered about.

Pretty straightforward. So what exactly does Product Management do? And here’s the fun part: even the executives of the company – the same folks who decided to introduce Product Management – may not be clear on what exactly it does!

Why do we even need Product Management? Infinitely worse is when folks secretly question the decision to bring in Product Management. This is sometimes prevalent at the department level.

The thinking goes this way: “We’ve been successful all these years without it, so why do we need it now?” Product Management represents a disruption to tradition and the status quo. As such, it is seen as a threat. We humans typically don’t embrace change so readily. In one company, IT had historically written the business requirements and the business was more than happy with this arrangement. When Product Management came into the picture, the battle lines were drawn!

The scapegoat syndrome: A common way for other departments to deal with the perceived threat is simply to blame Product Management for anything and everything wrong with the product. Suddenly Product Management is getting blamed for deals not getting closed, because the product does not have the features desired by the last “hot” prospect. If the product has holes, Product Management is called to task for writing poor requirements. If customers don’t respond to marketing, Product Management is accused of not understanding the customer. If customers report bugs, Product Management is asked to immediately identify fixes. Product Management becomes everyone’s favorite punching bag. It’s amazing how fast this happens.

The bottleneck syndrome: Somewhat related to the scapegoat syndrome, except this one is often self-inflicted. The new Product Manager declares, “Product Management owns the product.” And sure enough, soon he or she does indeed own everything to do with the product. All decisions, all issues, are swiftly sent to the Product Manager, who quickly gets swamped with putting out one fire after the next. Pretty soon, no department is getting the support it expects, the backlog piles up, delivery timeframes get jeopardized, the execs are still waiting on the product strategy, and everyone is pointing to Product Management as the bottleneck.

Eyes wide open

So before you introduce Product Management into your organization, or sign up as the first Product Management employee, be mindful of these traps. In my next post, I’ll share hard fought lessons on how you can avoid them and prepare for long-term success.

Have you ever been one of the first product management employees hired into an organization? Please share your story. I’d love to hear from you!

Read part 2.

 

Different worldviews of your product

Ash Maurya published an excellent post he titled, “The Different Worldviews of a Startup”1, in which he made the following astute observation:

“Different people — entrepreneurs, customers, investors, advisors, all see a startup differently.” — Ash Maurya

Spot on. He starts his post as follows:

In his book, “All Marketers Are Liars Tell Stories”, Seth Godin defines a “worldview” as the set of rules, values, beliefs, and biases people bring to a situation. He offers a strategy of not trying to change a person’s worldview, but rather framing your story in terms of their pre-existing worldview.

Boy, I wish I had this insight when I started out as a product manager! It totally applies to how product managers need to manage their stakeholders and partners with respect to their products. You need to tailor how you pitch your product strategy or business case to your audience based on the things they really care about.

And so with all due respect to Ash’s post, I will take the liberty of adapting his post to the discipline of product management. Similar to what he did in his post, I’ll illustrate this concept using the Product Canvas. If you’re unfamiliar, it’s a one-page encapsulation of the most essential elements that define your product strategy.

The Product Canvas

As Ash pointed out, different people see your product differently. I’ll expand on Ash’s post by discussing the different world views according to some of the different stakeholders a product manager has to deal with inside an organization.

Product Managers

Product Manager's world view

Product Managers, particularly those from technical backgrounds, are naturally drawn to the Solution box. Even yours truly. 🙂 They tend to spend a disproportionate amount of time on defining the features of their solution. As Ash puts it, “they fall in love with ‘awesome’.”

That’s why, like Ash did with his version, I kept the Solution box on the Product Canvas purposely small. This is not to replace user stories or a proper product definition. Rather, for one, to think about what are the most important elements of your solution that satisfy the primary problems of your target customer, as captured in the Problem box. Secondly, to make clear that the other components of your product strategy are equally, if not sometimes more, important.

Customers

Customer world view

I want you to write this down. Ready? Here it is:

Customers don’t care about your solution.

Write it down. Read it. Read it again. Sear this into your brain. Live it. Breathe it.

Customers care about only one thing: solving their problems. So to get them to care about your product you need to convince them that you understand them (identity), and then offer them something compelling that will solve their problem (your value proposition). How many times have we been told as product managers that customers don’t buy features, they buy benefits?

If you get these first two right, their next question is, “What’s it going to cost me?”. What they’re evaluating here is whether the price of your proposed solution is commensurate with its perceived value. (Value as perceived by them, not you.)

VP of Marketing

VP of Marketing world viewMarketing folks tend to naturally think about the market and customer first. Your VP of Marketing will be thinking about who are your target customers, what’s the plan to reach them, and how to measure the success of any marketing efforts. They know customers are bombarded with lots of noise, so your Marketing VP will be keenly interested in how the value prop of your product will be messaged, and its competitive positioning. (You do know who your competition is, don’t you?)

VP of Sales or Business Development

VP Sales worldview

Sales is interested in customers from the perspective of having a pipeline of hot leads. In particular, Sales will be trying to figure out who is that first named customer to whom they can take your product and quickly close a deal.

Sales folks love to talk about a product that “sells itself”. What they’re saying is they want you to have figured out who the customers are, and that you’ve built a massively appealing solution for them such that they’re thirsting for your solution.

Sales will also be keenly interested in pricing. It’s not just about their commission. (Well, it is about their commission, but stay with me here.) Many Sales folks look myopically at just price, because they’re worried about being undercut by a low-cost competitor. However, a good Sales or Business Dev exec will want to ensure your product’s price not only provides enough margin, but also communicates a value perception to the customer.

And that gets us to competition. Sales wants to be well-prepared before getting in front of customers. So be prepared to talk about what solutions customers may be using or considering, and how your product is positioned against these alternatives.

VP of Operations

VP Ops world view

Ops will want to assess the operational risk of delivering, fulfilling, distributing and supporting your product and marketing efforts. Ops will want to talk about business processes — if existing ones will be leveraged, will they need to be changed, or new ones created. And they will be looking to do these as efficiently as possible.

VP of Engineering / CIO

VP IT world view

When I talk software engineering folks through the Product Canvas, one of the most common questions I get is about capturing technology risk. They want to understand what it is you’re asking them to build (business/product requirements) so they can assess impacted systems and platforms, resource assignments, and architectural fit, in order to estimate the level of effort. They’ll want to understand if your product will require new technologies to be adopted, and if so, what that means in terms of skills sets and integration requirements. These considerations will impact the cost of developing, building and supporting your product.

Executives

Executive world view

Ok, saved the best for last…

Here, I’m talking about the senior execs in your organization who prioritize resources and approve operational budgets and capital investments.

Now, I want you to write this down too. Ready?

Executives don’t care about your solution.

Ok, maybe that sounds harsh. Maybe they do care. A little. But what they’re really doing is weighing your product as an investment. In other words, ROI. Similar to startup investors, executives are weighing the risks and opportunity costs of your proposed product strategy. Because they could easily allocate resources to something else they deem more worthy.

Executives do care about the customers you’re targeting, but less in terms of who they are, and more in terms of how many. In other words, market size, or more specifically, the addressable market.

They also want to know how much of it can be captured — in other words, market share. They’re doing the math of multiplying those numbers against the intersection of your revenues and costs to figure out the potential ROI.

For them to believe in your proposed ROI, they’re going to be interested in metrics. How will you know you’re being successful? What milestones will you need to hit? You need to figure out what metrics have line of sight to revenue and profit.

Ash makes a great point about traction: “If you have good traction, you can almost always convince the right investor to write you a check.” True for product managers too. If you can demonstrate traction, you’re more likely to get buy-in from your execs, and that means knowing how you’re defining and measuring success.

Finally, executives are often concerned about brand defensibility and differentiation. Especially in the case where the company has made heavy investments in its brand, execs will be evaluating whether your proposed solution will have a beneficial or detrimental impact on brand value.

Each of the boxes in the Product Canvas represents a risk or objection you must overcome towards building a successful product strategy. The true job of a product innovator then is to systematically de-risk their product strategy over time. To quote Ash one last time, “It helps to appreciate the different world views other people carry with them and frame your story accordingly.”

1“The Different Worldviews of a Startup”, Ash Maurya, LeanStack

“Stakeholder Development”: Using Customer Development on Internal Stakeholders

In my last post, I introduced the Product Canvas — my iteration of the Business Model Canvas — as a simple and quick way to capture my idea for a product. I’ve also used it as a communication tool to share my product vision and get early feedback, which is critical in the beginning stages of exploring a new product opportunity.

I’ve been sharing the Product Canvas with anyone who’s asked, and early feedback has been encouraging. One of the biggest things that seems to be resonating with folks is the Key Stakeholders box.

Product Canvas - Key Stakeholders

Look, I’ll admit, managing stakeholders is cumbersome, tiresome, and at times a pain. There, I said it. Admit it: you’ve felt that too. In my research on the business case process, a large majority stated that maintaining stakeholder support and alignment is important, but a challenge.

But I’ve learned the hard way that identifying and aligning stakeholders is really important for any initiative. So that’s why I put it in the Product Canvas. The reality is lack of stakeholder support can kill any brilliant idea at any stage.

When I came across Steve Blank’s Customer Development methodology, I wondered if its principles could be applied to internal stakeholder support. In other words, I wondered if it was possible to “develop” stakeholders too?

Here’s the Customer Development process. Steve’s bottom-line advice is to “get out of the building”.

Customer Development

So if apply this to “Stakeholder Development”, I’m thinking the process would look something like this:

Stakeholder Development

In this case, the bottom-line activity is to “walk the building”!

I figured this provided me as good a workable framework as any to identify, build and grow stakeholder support, and then I decided to put it to the test.

Through much trial and error, here are some tactics I’ve applied to Stakeholder Development. I’ll admit I haven’t fully cracked the code, and continue to experiment and learn. By sharing here, I’m hoping others may try as well and share their feedback.

I try to follow a systematic process for identifying my stakeholders, sharing my vision, capturing their feedback, and creating traction. I’ve been experimenting with applying Lean Startup’s Build-Measure-Lean loop for the purposes of doing this, and over time, I’ve developed a basic meta pattern:

stakeholder_dev_loop

So now that I’ve got a workflow I can follow, my first step is to identify who I think are my primary stakeholders, and I capture this in the Key Stakeholders column of my Product Canvas. Sometimes I already know ahead of time. In that case, I simply list them in the Product Canvas. But I have been in situations where I wasn’t entirely sure who were my key stakeholders. In this case, I capturing my hypothesis for who they may be.

I also try to identify a possible executive champion or sponsor – something I’ve learned is practically a requirement in a larger organization to ensure the success of any initiative.

So my Product Canvas could look something like this:

Product Canvas - Key Stakeholders example

I’d have actual names in the box, of course. If I don’t know who my executive sponsor will be (insider’s tip: it’s not always your boss), I don’t put a name, but I definitely call it out so it’s always at the forefront.

Next, I formulate hypotheses to approach my potential stakeholders. Going back to the Stakeholder Development flow above, notice a key question is “What are their agendas?” Remember: everyone has their own set of priorities. Some are visible, like a project deliverable; but some are invisible, like organizational political pressures. (Like it or not, these exist.) The more knowledgeable I can about their priorities, the better I can position myself to either gain their support or counter their arguments. At worse, I’ll have identified a potential detractor early on.

I then “walk the building”, reaching out and setting up meetings. For stakeholders with whom I don’t have a close relationship, who barely or don’t know me, I try to figure out ways to get an intro, just like one would do with customer interviews.

Setting up and conducting these conversations may be time consuming, but they are invaluable to validate who are my real stakeholders, and what I’ll need to do to get their buy-in.

I maintain a simple log to track my progress that I call my Stakeholder Development Tracker:

Stakeholder Development Tracker

There have been times I’ve discovered that someone who I thought would be an important stakeholder, actually isn’t. Great: I just mark their Role and Status as as N/A, and move on. Other times, I discover that someone I originally hadn’t identified is actually going to play a significant role in the approval and/or execution of my project.

Stakeholder Development Tracker Example

As I validate who are my true stakeholders, I update my Product Canvas.

product-canvas-key-stakeholders-iteration

These stakeholders are the ones I really want to focus on, the ones with whom I want to create traction. If I play my cards right, I can convert them from supporters to advocates to where they are actually personally vested in the success of my initiative.

As I said, I’ve been experimenting with this as a framework. It’s a work-in-progress, and I’ve enjoyed some success. Give it a whirl yourself, and let me know what works or doesn’t. If you have an approach to Stakeholder Development that’s worked for you, please share.

Introducing Product Management into an Organization

I recently wrote a guest post on the popular OnProductManagement.net blog about the pitfalls to look out for in introducing product management into an established organization. In my next post, I’ll share lessons learned from my experience in how product management can be set up for long-term success. If you have ever been through this experience either on the organizational side or as a product manager, I’d love to get your thoughts.

Many thanks to Saeed Khan for providing me the opportunity!

Like This!

Add to: Facebook | Digg | Del.icio.us | Stumbleupon | Reddit | Blinklist | Twitter | Technorati | Yahoo Buzz | Newsvine