Why Product Managers are worth their weight in gold

Why Product Managers are worth their weight in gold

Part 1: Product Managers Gold Series – Setting Strategic Direction

This is Part 1 of a series of articles we will publish on the role of the Product Manager within the new product development process.

A Product Manager plays one of the most valuable roles within your organization: managing the ongoing profitability and viability of their product/category. This very broad and critical charge requires attention to specific responsibilities requiring specific skills and talents. This article will focus on the responsibilities as they relate to new product development.

The driving force of a product/category is its strategic direction and framework.  For your company’s innovation/new product development efforts this includes the set of Product, Platform, Market and Technology strategies, as well as Product and Technology Roadmaps.   These elements focus resources on activities that translate into innovative, differentiated and profitable products. A Product Manager that defines and executes appropriate strategies that yield a sustainably profitable product/category is truly worth their weight in gold.

Before your Product Manager gets started

In order for your Product Managers to develop the appropriate strategic framework, they first need clearly stated and communicated business and innovation strategies defined by senior management.

The business strategy defines the long-term direction, or mission, of the organization, how the organization will achieve that mission, and what measurements will allow the organization to identify progress against or achievement of that mission.

The innovation strategy defines in what ways and to what extent the organization will use innovation to execute its business strategy. This boils down to defining what resources and the extent of resources to be allocated to innovation, and the types of innovations or levels of risk the organization will undertake in the pursuit of innovation.

Why is strategy so important? We’ve worked in organizations that have clearly stated strategies and those that don’t.   The difference between the two is like night and day.  If I had to choose two words to describe the company with strategies, and those without it would be ‘clarity’ vs. ‘chaos’.

The organizations with strategies provided clarity to the team and organization.  The strategies provided direction on where the organization was going, and how it was going to get there.  Everyone had their marching orders, they knew what to do and their efforts were aligned.  It was not uncommon to see the Product Managers continually referring to these strategy documents because they provided a framework and an understanding of the resources and constraints they have to work with.

In contrast, in organizations without clearly stated business and innovation strategies we’ve seen a lot of valuable time wasted by product managers forced to develop their product/category strategies in a vacuum, trying to  infer the direction of the organization or worse, setting direction without regard to the mission of the larger organization.  This situation creates chaos for the entire organization as the various functions try to cope with different agendas, different resource requirements and different priorities.

It takes effort and time on the part of senior management to develop business and innovation strategies, but the payoff is tremendous.   Ensure that your Product Managers are well-equipped with the strategic direction of your organization.  They will then be able to develop appropriate and aligned strategies for their products/categories.

The Product Manager’s role in defining new product development strategy

The following content provides an overview of the five key strategy documents that Product Managers should consider when developing their product/category strategy framework for guiding new product development.

Product Strategies

Product strategies help guide your organization in the development and evolution of categories, product lines and products.  The product strategy includes the goals for new product development within each category ( e.g. market share, revenue, new markets), the arenas of strategic focus (the markets, technologies, product types to be focused on), spending/resource allocation for each arena and a  timeline showing the planned new product introductions.

Platform Strategies

Platforms enable your organization to create new products faster and more efficiently by bundling together elements that can be common across multiple product lines.  A platform strategy guides your organization in the development of platforms and derivative products.  The important elements of the platform strategy are defining the capabilities and limitations of the platform, as well as creating the platform’s point of differentiation.  The platform strategy is also an integral part of developing product and technology roadmaps.

Market Strategies

Market strategies guide your firm in the development of markets and distribution channels.  The market strategy defines who the target customer is, what segments will be served, what is the value proposition or point of differentiation when compared to the competition, and what distribution channels are needed to reach the customer.

Technology Strategies

Technology strategies guide your organization in the acquisition, development and application of technology to gain a competitive advantage.   The elements of the technology strategy include identification of the source of technology, as well as the timing of implementation to support the product strategy timeline.

Product and Technology Roadmaps

Product and Technology Roadmaps provide the graphical representation of the current and planned evolution of products and platforms that match market need to specific technologies.   They basically illustrate the portfolio of projects that the organization needs to work on in order to achieve its business strategy and be successful.  It especially helps the organization with forecasting required technology and the skills that need to be acquired.

Communicating the New Product Development Strategy

To be effective, these strategies must be agreed to and supported by senior management, and clearly communicated to everyone involved in new product development. Progress against these strategies needs to be openly and continually monitored, with adjustments made to react to changing market, industry and technology conditions. We recommend monthly new product development portfolio review meetings and quarterly strategy meetings with the Product Managers presenting their findings to the senior management team.

Product Managers have the ability to make a real difference for your bottom-line.   You will quickly realize that they’re worth their weight in gold by 1) Ensuring your product managers have access to business and innovation strategies created by senior management, 2) Ensuring your product managers have the time to create and update their product strategies on an on-going basis, 3) Communicating the new product development strategies to senior management and the project teams, and regularly monitoring progress.


Product Opportunities Assessment

Opportunities for new products exist all around us, in every market, even mature markets. This is because what is possible is always changing. New technologies are constantly emerging, new people with new talents join your company, and competitors come and go. The product manager must be able to quickly evaluate opportunities to decide which are promising and which are not, and for the ones that look appealing, which ones should be pursued, which are best left for others, and which ideas are not yet ready for productization.

In many companies, it just comes down from above that we really need to do this product. In other companies, the marketing organization determines what products are needed.

In either case, too often the process of deciding whether or not to build a product is left to intuition (or worse, a large customer will offer to fund a “special” and this becomes the basis for a product effort).

Typically someone on the business side or in marketing will create some form of a Market Requirements Document (MRD) that is intended to describe the problem to be solved, and usually includes a business justification as well. The purpose of the MRD is to describe the opportunity, not the solution. At least that’s the theory. In practice, many companies don’t really do MRD’s, or if they do, they’re essentially product specs that are called MRD’s. When true MRD’s are done, they suffer many of the same problems as PRD’s – they take too long to write, they aren’t read, and they often don’t answer the key questions they need to.

The result is that many product managers ignore the MRD. But the problem with not doing anything and just jumping right into the product is that it is generally a good idea to look before you leap. The challenge is to do this in a quick, lightweight, yet effective manner.

I consider this “Product Opportunity Assessment,” as I prefer to call it, an extremely important responsibility of the product manager. The purpose of a good product opportunity assessment is either to a) prevent the company from wasting time and money on poor opportunities; or b) for those that are good opportunities, to understand what will be required to succeed.

Fortunately, it’s really not that hard to do a useful product opportunity assessment. I ask product managers to answer ten fundamental questions:

1. Exactly what problem will this solve? (value proposition)
2. For whom do we solve that problem? (target market)
3. How big is the opportunity? (market size)
4. What alternatives are out there? (competitive landscape)
5. Why are we best suited to pursue this? (our differentiator)
6. Why now? (market window)
7. How will we get this product to market? (go-to-market strategy)
8. How will we measure success/make money from this product? (metrics/revenue strategy)
9. What factors are critical to success? (solution requirements)
10. Given the above, what’s the recommendation? (go or no-go)

The hardest question to answer is usually the first, which surprises people because it sounds like the easiest. But ask most product managers what problem their product is intended to solve, and you usually get a rambling list of features and capabilities, rather than the a crisp, clear and compelling statement of exactly the problem that’s solved.

Another difficult problem can be in assessing the size of the opportunity. You can get thoughts on this from industry analysts, trade associations, your finance staff, and from your own bottom up calculations. This is a topic in itself, but for now just remember to be conservative and realize that not every opportunity needs to be a billion dollar market.

The “go-to-market” strategy is especially important as that describes how this product would be sold, which can have very significant impact on the product requirements.

The solution requirements refer to any special needs or requirements that were identified during the investigation. Again, we’re not describing the product here but rather making clear any dependencies or constraints. For example, if this is a product that will be sold through system integrators, then these types of partners have requirements around extensibility of the products they deliver. Similarly, there may be branding or partnership requirements.

A product organization is all about pursuing good opportunities and providing great product solutions. Opportunities for new products are everywhere, and it is important that the product manager be able to effectively evaluate new opportunities and identify those that have the most potential for the company. It is just as important that bad product ideas get identified at this stage, before significant time and cost is lost chasing them. Choosing the right set of products to pursue is among the most important decisions a company will make.

It is important that the results of the product opportunity assessment be presented and discussed with senior management, and that the company make a clear go or no-go decision on whether to pursue a product to meet this opportunity. If you do decide to proceed, you will be much better informed as to what you are getting yourself into and what it will take to succeed.

So what do you do if the CEO tells you that this is what we’re doing, so just get to work on the product? First, realize that there are sometimes strategic reasons for doing a product, so you might need to pursue a product even when it’s unlikely to succeed in the market. That said, I have found that doing this lightweight, quick product opportunity assessment is still valuable in that I become much better informed about what this product involves. It is possible that what you learn will change your CEO’s opinion, but more likely it is a good opportunity, and your CEO was right to want to pursue it, but at least now you know what you’re up against if you are to succeed.

Everything is a Product Management

The basis of the post is this: Everything is a product management problem. Not just the product. Not just features. Not just platforms. Everything you do.

The same techniques and skills you use to manage product development can be applied to your startup, your business plans—and you, yourself.

It’s about compromises and resources and time. It’s about ship dates. It’s about controlling feature creep. It’s about making go/no go decisions. It doesn’t matter whether you’re an engineer, marketing, management, or sales. In the startup world, everything is a product management problem.

With that in mind…

Everything is a product management problem

Now, I’m no expert in product management.

I’ve spent a lot (a lot) of time sitting in product management meetings and listening. My primary contribution to product management meetings?

  • Meeting #1: Me: “When are we scheduled to launch? What’s the date?”
  • Meeting #2-#999999: Me: “Does that affect the launch date? Is the launch date slipping?”

Yes, vital component. That’s me.

But it’s good. Because when I keep my trap shut, I actually listen, so I’ve managed to pick up a few things here and there.

And here’s where the worm begins to turn.

So, the other day, I’m staring off into space, thinking about product management, and this occurs to me: Everything is a product management problem.

How so? Well, let me outline some of the high points of product management.

  • Timeline / Road map / Lifecycle. Every product has one. The really good ones detail the life of the product, from conception through demise. On it, you can see every upgrade, every feature, every release, every date. Everything that will happen to that product. This is the plan. For the entire product. Everything that happens occurs here so that it can be seen in the context of the product life. And every change that is made is reflected here. All the new features, all the slips, all the last minute requests, all the executive force ins. Not only is interesting and vital to managing the process, it’s one hell of a document for the post mortem. And it’s the polar opposite of our next item.
  • Trade offs and compromises. This is the product manager’s preeminent skill. Everything in product management is a series of trade offs. When is that resource available to build that functionality? Regardless of when that functionality is built, when do we release it? What does the market want? What does the company want? What do we do to incorporate this last minute requirement? How do we retool based on the usability tests? Everything is a balancing act for the product manager. You can’t do everything at once. And you can’t do everything before launch. It’s a constant game of ready, fire, aim. What is attainable versus what is necessary.
  • Resource management. Once locked, loaded, and focused on target, how do we manage the resources at our disposal? Are we going to wedge in some additional functionality while we have engineering cycles? Are we going to bring in outside help to get us through this rough patch? Can we rely on a single engineer to bring everything to fruition? What if that person falls ill during QA? How much do I have to spend to get this done? Can I buy more time? Can I buy more resources? Do we have to build? Can we partner? Can we acquire?
  • Translation. The product manager is a Rosetta stone of sorts. Sitting somewhere between the business aspects of having a product and the labor required to bring that product to fruition. In high-tech, as an example, engineers don’t generally want to hear about the business reasons behind feature #479. They want to know the spec and they want to know what technology is at their disposal to create the feature to spec. Conversely, the CEO generally couldn’t really care less if you’ve created an AJAX implementation or used C#. S/he wants to know if the customer will be jumping for joy or throwing up all over it.

So taking those high-level points, shouldn’t we all be product managers for everything we’re doing? Shouldn’t we be product managing our startups? Product managing our investors? Product managing our employees? Product managing our product?

I mean, couldn’t your startup use some product management? A timeline? A life cycle? An attainable list of features and functions to be launched at specific intervals? What does version 3.5 of your startup include? Is it Windows, Mac OS, and Linux compatible? What mobile platforms do you support? Where are your feature/function gaps that could move your startup forward or doom it to inadequacy? What features do you want versus what functions does the business want? What happens when a competitor enters the market?

How’s your startup’s usability?

Think about it. Your startup will be better for it.

Product Storyteller – Essential for Product Development

There’s an interesting question on Quora right now:

If you had to pick between an amazing product designer or an amazing engineer to build a new company around, which would you pick and why?

During any product development, the essence should always be targetted at ‘WHY’ than being or ‘How or What’.

If your execution focuses on the how and what of a product whereas in a world where consumers are inundated with choices, products that want to be noticed and adopted must be rooted in the why, in this case you are bound to face issues like scope creep, missed deadlines, overspent budgets, frustrated teams and, ultimately, confused users.

A product is more than an idea, it’s more than a website, and it’s more than a transaction or list of functionalities. A product should provide an experience or service that adds value to someone’s life through fulfilling a need or satisfying a desire. But who defines these values?

Let’s face this: The executive and the stakeholders would eventually define or identifies the idea…but after that who would be there in the organization to actually deliver the value to the customer? May be a Product Manager, Marketer, Technologist, or designer? Or perhaps…well…The Product Story Teller?

Who are the product storytellers? A bit of all these: matchmaker, marketer, technologist, and artist, the product storytellers ask questions, find answers, and figure out how to distill a vision or idea into a product story. They develop a plot, identify the people, and shape the product around the specific values it should offer consumers.

How critical a Product story teller can be?

The product storyteller facilitates collaboration and co-creation. Today, many companies have their product and marketing groups disconnected from each other.

Marketing decisions are often made at the executive level—much higher than where product decisions are made.

The result is that marketing tells one story, and the product tells a different story. In the end, consumers are left to put together the conflicting messages and try to determine why they should engage with the product.

A product storyteller should be positioned in the company to help break down the walls between all groups, facilitate the development of a single story, foster collaboration between groups, and ensure that every interaction a consumer has with a product or brand maps back to that story.

Share and evangelize: A common understanding of the product story allows a team to incubate a shared vision. This vision turns into passion, and people with both passion and vision are more likely to produce products that others want to use. Without a firm understanding of the why, the team risks becoming task focused, losing sight of the big picture, and deflating any sense of empowerment or excitement that once existed. When this happens, consumers and the team feel the effects.

In his book, A Whole New Mind: Why Right-Brainers Will Rule The Future, Daniel Pink explains that we’re in the “Conceptual Age” and that skills that were revered in the Industrial Age and Information Age are not as integral to where we are as a society today. Pink writes:

We’ve progressed from a society of farmers to a society of factory workers to a society of knowledge workers. And now we’re progressing yet again—to a society of creators and empathizers, of pattern recognizers and meaning makers. We’ve moved from an economy built on people’s backs to an economy built on people’s left-brains to what is emerging today: an economy and society built more and more on people’s right-brains.

The challenge today is that we face a shortage of storytellers because our current organizational structures and cultures are not optimized for the activities involved in storytelling, reason being : Ownership of product value,  communication disconnects, vision not in line with the original vision…

Marty Cagan, a product management and product strategy expert, addresses this issue in his book Inspired: How To Create Products That Customers Love. Cagan notes that there are two key responsibilities of the product manager: “assess product opportunities, and define the product to be built.”

The product storyteller should synthesize rather than analyzes, should see the big picture rather than becoming stuck in the details, and ensure that all product interactions and touchpoints form a cohesive and value-based consumer experience.

So whether you are at a small start up or a large organization, whether you are a founder, executive, technologist, designer, manager, or marketer, ask yourself this: do you know your product’s story? And perhaps more importantly, who creates your product story?

Courtesy : UXMagzaine

Scope of your Product….

While going through an interesting blog by Jeff Lash (www.jefflash.com)…he explained in detail about defining the scope of the product and as a product manager you yourself should take this responsibility…by doing a proper market analysis and thorough understanding of the customer, as to how do they see it…

A bad product manager, define the scope of her product as how she see it. After all, you’re a product manager, right? You’re not a supplier manager, or a vendor manager, or a promotion manager. You can’t be held responsible if the free gift you offer with your product breaks within the first week. This is so very true for quote a few of Product Managers. And for them it becomes all too easy to delegate the stuff they by themselves should be responsible to complete.

It’s not your fault if your program won’t install correctly on computers with certain virus software. How are you supposed to know when a partner website changes their design without notifying you so that all your links to them break. In cases like this the best only thing you can do is just let customers know it’s not your fault and tell them to whom they should be complaining.

A good product manager, define the scope of your product as how the market sees it. You should know in and out of your product, you know who is responsible for what within the company and probably who dropped the ball on something outside of the “official” scope of your product. You need to forget all of that. What really matters is the scope of your product from the point of view of the customer.

Everything that the customer experiences in relationship to your product is ultimately your responsibility. Delays fulfilling a rebate may technically be because of mistakes made by the company handling the payment processing, but it reflects badly on your product. Broken links from your website to another may be because of changes the other site made, but customers perceive it as a problem to your site.

It’s very easy to draw the line and say that certain things are outside your control. That’s a short-sighted approach, though. Ultimately, those within the organization and outside it will look to you when these types of issues arise, and for the overall good of your product (and your career) you need to step up and take responsibility.

Good Manager vs Bad Manager

Ben Horowitz is a venture capitalist in Silicon Valley. He was the CEO of Opsware before he became a VC – so he has real-world operating experience as well, and I love to read his blog regularly.

I was reading one of his recent posts, which linked to a document titled “Good Product Manager, Bad Product Manager”. Ben wrote it when he was the Director of Product Management at Netscape. The purpose of the document was to share his expectations with product managers in his team.

Read on for the link to Ben’s PDF and my favorite part of the document…

I love this part of doc…

The whole document is excellent – but my favorite part is:

Good product managers focus the team on revenue and customers. Bad product managers focus team on how many features Microsoft is building. Good product managers define good products that can be executed with a strong effort. Bad product managers define good products that can’t be executed or let engineering build whatever they want (i.e. solve the hardest problem).

Here is the link to Ben’s PDF – check it out. Whether you’re a Director or VP of Product Management (i.e. responsible for managing product managers), or a Product Manager yourself – the PDF is an excellent read.

Essential for Product Managers : Writing Effective Use Cases – Book Review

Writing Effective Use Cases Front CoverAlistair Cockburn is a well-renowned expert on agile development and use cases; his book Writing Effective Use Cases is a “must read” for all product managers.  This is a book which will become part of your core reference library, never far from your reach.

For someone who has never written a use case, this is an excellent starting point, covering all you need to know about use cases to be successful.

For those that have written use cases, I am confident that you will find many new valuable nuggets of information that will help you in your job.  The book is manageable in length (270 pages including appendices and index) and very practical with many examples of uses cases throughout (including examples of bad ones). The most valuable aspect to the book is Cockburn’s professional advice and tidbits that he sprinkles throughout the book.  Anyone who is familiar with Alistair Cockburn’s work knows that he has a great deal of experience, and it shows in this book.  This book is short in theory and long in real-world examples.

Cockburn refers to use cases as “scaffolding” that connects various pieces of the project, which is very true.  Use cases are crossed linked to requirements, user interface designs and test plans, creating a traceability matrix throughout the lifecycle of the project.  Cockburn dedicates a chapter to how use cases fit in the overall process.  Managing the entire body of use cases is just as important as writing them.

A big part of any product manager’s job is time management, and Cockburn addresses this in the book.  It is not feasible to write detailed use cases right from the start, and it certainly cannot be done for all of the potential uses cases.  Cockburn stresses the importance of “warming up” with use case briefs or narratives, and then working towards more detailed, fully dressed use cases.

Best part is the section on differentiation between requirements and use cases – this is an important concept for product managers to understand.  In short, use cases really are requirements.  Properly written, use cases describe the behavioral requirements.  However, with that said, use cases do not deal with all requirements such as the non-functional ones (external interfaces, performance criteria, documentation standards, etc.).

As a product managers you may have your own format or preferred method for use cases, Cockburn provides many examples of different use case styles.In short the UCs are “fundamentally an exercise in writing prose essays, with all the difficulties in articulating good that comes with prose writing in general”. The use cases must be easy to read, short and clear for all stakeholders to understand.

Software Product Management – Trends

No. 1 – Portfolio Prioritisation

Are you working on the right things? The discipline of portfolio management isn’t new, but applying it in product organisations is much more recent. Product managers should ask themselves – what is the competition doing that I’m not? Are we prioritising our product portfolio so that our hottest products get to market more quickly?

Successful portfolio prioritisation is about several key factors. These include driving revenue into your organisation and measuring it through a variety of financial metrics; and aligning with the corporate and product strategy, ensuring that the priorities move you in the right direction for your particular company, product or product line. It’s also about securing the resources to deliver the product, and evaluating and measuring the tolerance to any risk involved. Most companies will also want to think about the impact of any activity on their brand, and whether the proposed strategy allows for successful leapfrogging of the competition.

The most recent factor that has come into play is sustainability. What will the impact be on the environment? Taking this into consideration, whilst evaluating the portfolio, is key.

And last, but of course not least, is the ultimate question – how will the product be received by our customers.

Software solutions, such as Planview Enterprise, include an investment analysis, which helps product managers to put in place a ‘what if’ scenario plan. This will evaluate product, features, projects and programmes and align these against the targets you’ve set, assessing whether you have the capacity to deliver. This functionality provides a product management team with the capability they need to drive products onto the market.

No 2 – Resource Management: How do I best utilise my people?

You must have the resources to execute, or you can’t deliver. One of the top three ‘pain points’ highlighted in the Planview benchmark study revealed earlier this year, was having too many projects for the resources available. It was clear from the results that companies wanted to be sure that their precious resources were aligned to products with the greatest strategic and financial returns. However, many respondents to the survey reported that they relied on manual approaches, such as spreadsheets to manage complex product portfolios.

The game changer, therefore is about three things: the first is strategic organisational planning, the second is ensuring that the resources for ongoing development are in place and the third is about dealing with the change that comes with all this planning.

Product managers have to consider how they are going to avoid resource bottlenecks, reduce risks, meet the launch date, eliminate resource cost over-runs, be proactive and respond to change in the organisation. If you find the best solution to deal with resource capacity planning at the outset you will be able to deliver on time and on budget.

No 3 – Agile Product Management: Why should I care?

‘Agile’ is not just a development concept. It is an approach that in product management should be used every single day in order to do the job better. There are a lot of agile tools available from velocity and burn down charts through to backlog for the product. Why should you care? It all comes down to delivering what customers want. That’s the job of product development and how developers are measured. Being able to have a clear view into how a project is developing and managing it at every stage is critical. Agile means being able to feedback to customers and involve them in the decisions and in the progress being made, and it provides a central point for all product ideas and backlogs, which is essential if a member of the product development team is away or uncontactable. Agile also helps you to be flexible to change and to meeting customer needs and bringing them into the agile circle. Agile is also increasingly helping companies with quality, enabling them to test a solution or product throughout the development process. This is also a major time-saver.

No 4 – Social Product Management: Are product managers going social?

Are product managers going social – they certainly are. Most product managers probably follow the blogs and tweets written by other product managers in their sector, and possibly even respond to points that they are making.

Product managers are embracing ‘social product management’ as quickly as any other industry is incorporating ‘social’. From a product management standpoint it is very important to see what competitors, customers, analysts and industry experts are saying through social media. It helps to keep you abreast of issues that are arising and ‘in the know’ when industry experts outline their predictions or the next big trend. And if your competition has a big announcement you will want to be the first to know about it. Being on top of product social management is critical in terms of how product managers do their jobs moving forward.

Aligned to this is social collaboration. Imagine you are in the middle of a big product development, and your team is spread across the world. How do you keep on top of what is going on? Through social collaboration, in the form of video or voice conferencing, and this is now possible by simply clicking on a name in your product management dashboard – that’s getting social.

No 5 – Product Management Analytics: What data do I need?

Probably the most important question that a product manager can ask is how can I show the key data that illustrates how my project is moving forward? In order to meet management demands for clarity and progress reports, product managers have to be able to instantly access a product backlog, ideally from one location.

Through the analytics, product managers can answer management questions relating to the relationship between innovation, enhancements and customer requirements, and queries about cost, capacity planning, offshore resources and the date that the product it is due to release. A product manager might also want to provide a revenue forecast.

One of the most popular metrics in the analytics function should be a roadmap. This can be based on the release date, the product, even by the market. All the key items should be in one location, and all the information should be in real-time, so the product manager can provide current data to management very quickly. The automated roadmap saves time and effort and allows you to pivot the data so that it can be seen by different criteria.

The additional benefit of real time analysis is that when you are thinking about your portfolio and trying to decide where the priorities lie, you have access to all the other relevant information such as what the competition is planning, your brand values, your resource capacity and factors relating to sustainability. If you want to make a change, you can do this in real time and the metrics will change instantly in one screen.

These are the current game-changers, the activities that will put your product management ahead, enabling you to automate at every stage from ideation all the way through to launch. These tactics remove unnecessary, time-consuming tasks, and deliver to you all the analytics and information you need to product manage effectively.

A Product Manager? Who exactly this guy is…?

I often ask this question from myself as to what does it take to be a successful product manager. What do they do? Where do they come from? Why do they like sharpies so much?

In his book Inspired, Marty Cagan describes the job of the product manager as “to discover a product that is valuable, usable and feasible”. For me too product management is the intersection between business, technology and user experience (hint – only a product manager would define themselves in a venn diagram).

Key elements: A good product manager must be experienced in at least one, passionate about all three, and conversant with practitioners in all.

Business – Product Management is above all else a business function, focused on maximising business value from a product. Product Managers should be obsessed with optimising a product to achieve the business goals while maximising return on investment. Sorry, this does mean that you are a suit – but you don’t have to wear one.

Technology – There’s no point defining what to build if you don’t know how it will get built. This doesn’t mean a Product Manager needs to be able to sit down and code but understanding the technology stack and most importantly understanding the level of effort involved is crucial to making the right decisions. This is even more important in an Agile world where Product Managers spend more time day to day with the development team than with anyone else inside the business.

User Experience – Last but not least the Product Manager is the voice of the user inside the business and must be passionate about the user experience. Again this doesn’t mean being a pixel pusher but you do need to be out there testing the product, talking to users and getting that feedback first hand – especially in a start-up.

to discover a product that is valuable, usable and feasible – Marty Cagan

Manage what exactly?

Why do you need this breadth of skills? Because the role itself is incredibly broad and varied and you’ll be using them every day.

Vision: It starts with setting a vision for the product, which requires you to research, research and research some more your market, your customer and the problem they have that you’re trying to solve. You have to assimilate huge amounts of information – feedback from clients, quantitative data from your web analytics, research reports, market trends and statistics – you need to know everything about your market and your customer, and then mix all that information with a healthy dose of creativity to define a vision for your product.

Spread a Word: Once you have a vision, you have to spread the word in your business. Get dogmatic, evangelical even, about the utopia that is your product. And if you can’t get passionate about it – you’re in the wrong job or you didn’t come up with a very good vision. Your success, and that of your product, relies on every team member – from sales to developer – understanding that vision and being at least a little bit passionate about it as well.

And then you switch gears again and start building an actionable plan to reach that vision. A roadmap of incremental improvements and iterative development that take you step by faltering step closer to that final vision. This is when all that hard work preaching the good word pays off – and your team throw themselves into coming up with better designs, better code and better solutions to the customers problem.

Now we get really detail oriented, as you work day in, day out with the development team as a product owner – defining and iterating the product as you go, solving problems as they pop up and closely managing scope so you can get the product out on time.

The product is finally out there and suddenly you’re spending your days poring over data again – looking at how customers use the product, going out and talking to them about the product and generally eating, sleeping and breathing the product. Did you solve the right problem? Do your users get the product? Will they pay for the product? This is all about understanding your customer, I take this point that you have been doing this from past so many months for this product, but it is post product that makes life more easier for you and your customer.

And then you do it all over again. Now since we do not use the waterfall methodology anymore, this means we are not doing this step by step, we’re doing this for a dozen products or features at any one time, switching from strategy to tactics in the blink of an eye.

Want to give this a second thought?

Sure it’s a tough job but it’s just about the most fun you can have with your clothes on – certainly the most fun you’re going to get paid to do. You get to define the very essence of a product, design solutions to your customers’ problems, work with everyone in the business and play a very large part in your business’s success. We’re the unsung heroes of the tech world – or at least we’d like to think so…

Product Management : Lessons to be learnt

Product Management, is a tough job. And eventually becomes tough when you are venturing in to an unknown domain. However if though carefully, and learned carefully, this can be the most beautiful, soul searching experience for anybody:

Underlined are the few learnings from “Software Product Failures”…and you need not be an MBA to learn this.

Here we go:

  • Creating a new market is difficult and risky.
  • Changing people’s working habits is hard.
  • Social factors can make or break a product. The end-users didn’t see anything in it for them.
  • If the end-users don’t like a product, they will find a way not to use it, even if their bosses appear to be enthusiastic about it.
  • Talk is cheap. Lots of people telling you how great your product is doesn’t mean much. You only really find out if your product is commercially viable when you start asking people to buy it.
Consider this:
DRAMA (Design RAtionale MAnagement) was a commercialization of a University prototype for recording the decision-making process during the design of complex and long-lived artefacts, for example nuclear reactors and chemical plants. By recording it in a structured database this information would still be available long after the original engineers had forgotten it, retired or been run over by buses.. There are lots of social factors that work against engineers wanting to record their design rationale, including:

  • The person taking the time to record the rationale probably isn’t the person getting the benefit from it.
  • Extra work for people who are already under a lot of time pressure.
  • It might make it easier for others to question decisions and hold companies and engineers accountable for mistakes.
  • Engineers may see giving away this knowledge as undermining their job security.
So NEVER ever disengage the social aspect of a product development.
Try this and you will never run out of steam:
  • Force yourself to get out and talk to people. Ask their advice. Almost everyone will help if you ask them for feedback.
  • Force yourself to cold call a few businesses in your target market.
  • Create a plan of how to market your product.
  • Try and use your product as much as possible as you build it.
  • Get out of your comfort zone from day one
  • Do not have the mind set that the day you release version 1.0 is the finish line, it’s the starting line, so hurry up and get there.
By far the most significant problem is:
  • lack of market research
  • lack of marketing

With the benefitof 20/20 hindsight it seems blindingly obvious that we should:

  • spend a few days researching if a product is commercially viable before we spend months or years creating it
  • put considerable effort into letting people know about the products we create.