Continual, but elusive nature of Product Management

An article from Product Focus, entitled Product Management and the Impostor Syndrome made me realise the ongoing learning journey that product management provides and requires in order to master the art.

Their definition of impostor syndrome is

those affected cannot internalize their success and attribute it to external circumstances (“I’m just lucky”). They see praise as an overestimation of their abilities (“Oh, everyone could have done that”). On the other hand, failures, difficulties and slow progress are attributed mainly to their inadequacy (“I just can’t do it – others would”).

As one goes further on one's product management journey, one's skills increase - more and more scenarios have been tackled, more scars, more learning. Soon enough, what once was an eyeball-rolling challenge has become "Yeah, I'm sure I can pull that one out of the bag again".

Yes, Product Management is a diverse role - there is always more to learn - which it is continuously challenging and why I love the role..

This attitude of willingness to learn is good and important, but at the same time, we are often working at the limits (and beyond) of what we know. We are, therefore, not only exposed to inadequacies more frequently but, by pushing into areas where we’re not the expert, we also actively make ourselves more aware of them.
Product managers must retain their curiosity and embrace the aspiration of ‘lifelong learning.’ I believe impostor syndrome is just one side effect of our path to becoming better product managers.

Career Paths into Product Management and Product Marketing

Last week, at the joint meeting of the Cambridge Product Management Network and Cambridge Network, I shared my observations and thoughts about common (and not so common) routes that Product Managers & Product Marketers have taken to get to their current position. Céline Sharpe from FIS (formerly WorldPay) shared her practical experience.

To view the slides, please go to Career paths into product management and product marketing on SlideShare

In summary, there are three core skills that product managers / marketers need have their arms around:

• Proposition Development (eg Sales and Marketing)
• Technical Construction (ie Engineering)
• Value Realisation / Utility (eg User Experience, Implementation, Customer Support)

Given that technology innovation dominates the software industry then this is obvious. (Product Managers in the Food industry are likely to have Food Tech credentials, right??)

But there is a whole lot of other skills requires - and these are skills that can't be taught, but have to be learnt on the job:

• Human 'Savvy' (ie awareness or sensibility)
• Communication
• Trust
• Corporate 'Savvy'
• Leadership
• Project and Process Management
• Translation

See SlideShare for more details.

Rich Mironov on Product Roadmaps

The great Rich Mironov, a well-regarded product management guru, speaks about the negotiating your product roadmap for B2B software companies.

War stories, methodologies. An excellent video that can be easily consumed.



Rich was speaking at the Business of Software conference held at the start of October

I'm going to pull out one insight (amongst many):
4. Share trade-offs and scorekeeping with Sales leadership (at about 46 mins)

Rich talks of a mechanism by which the product management 'trades' the focus of the engineering team with the Sales team. His process requires Sales to metaphorically 'pay' for a feature - he uses a virtual token. This makes the Sales team prioritise which 'extra special' feature required for their 'super critical' strategic deal and then proceeds to pay for it.

Excellent concept - and one that doesn't apply just to Sales. I have applied it to Research as well:

"We really need Jenny to evaluate XYZ technology and blueprint a solution because she has the most applicable expertise."
"OK", I say, "What of the development plan in the next release are you trading out?".

Product Management is learnt by doing rather by studying

Noah Weiss, a senior product manager at Slack, Foursquare and Google, makes this quote in this article, Five Dangerous Myths about Product Management:

Product Management isn’t an academic subject that one can study; most people learn by apprenticeship. They have diverse backgrounds, murky responsibilities, and wildly varied role definitions across companies.

Although the sentiment is broadly correct, it implies that you can look to a mentor for guidance. Sadly, this simply isn't true. His quote would be better phrased:

most people learn by doing and most importantly, learning from their results.

The rest of Noah's article is worth a read. Some other nuggets:

They come from a wide diversity of backgrounds and relish wearing many hats.

A PM with a diversity of backgrounds is really useful: most product managers come up from the technical side, some come from the sales and marketing side, but they absolutely need to appreciate what's going on underneath other people's hats, both inside your own company and externally

[Product Managers]should be the ultimate facilitator: pulling the best ideas from their team, coordinating with cross-functional partners, and getting executive context. PMs should lay out well-researched tradeoffs, set timetables, and structure great discussions.

There isn't a good decision that a product manager can make, they make the least worst decision in the circumstances. Everyone can perfectly rightly say, "That's not a good decision", but on balance, that decision is the least worst option.

SCOTSMAN for sales qualification

My previous blog post about communicating the commercial imperative of products was originally prompted by how frequently I, as a Product Manager, have discussed sales qualification of a prospect with respect to product differentiation and competition.

Frequently I had shared my insight with the sales teams:

• "If customers says their problem is this, then this implies that they have solved this, this and this problem with  an alternative solution. As a result, they aren't a good prospect unless they have this characteristic."
• "If a customer is asking about this feature, then that implies that they are currently used competitor X's product, as we know that this is their weakness. It would be best to differentiate our product by talking about this business problem."
• "Competitor Y is particularly strong in that market, that prospect looks tough to bring over the line."

This often leads to a conversation about sales qualification in general. Here's a mnemonic called SCOTSMAN from salesplusprofit.com:

Sharing the commercial imperative of our products

I find that as a Product Manager or a Product Marketing Manager, we spend a lot of time communicating the value of our proposition's features, differentiating capabilities, value and how one's solution moves our customer's business forward to our sales and customer service teams.

But this message needs to be widely understood across the company.

Scenarios that I have frequently encountered:

• Software Engineering develops features because they are 'cool' or based on the CEO saying, 'Wouldn't it be great if ....'
• Software Engineering spends ages crafting out a solution to a long-tail problem where an 80/20 approach would be much more valuable
• Testing validates the product feature based the product specification from Engineering (see previous point), not based on how the product would be used in an operational environment. 
• As a tester in Dallas, Texas, I recall spending days testing a product feature only to be told that this particular narrow shard of functionality gets used about 5 times a year and only as a tool of last resort and only by highly experienced users who didn't need all the defensive protection from poor data entry or illogical data flows that had been tirelessly testing.
• Research teams working on the functionally interesting problem and NOT on the biggest risk to the overall commercial success of the suggestion - which is frequently customer adoption in a competitive market. Poor research (or usually no research) is a HUGE waste of Development's team - a topic worthy of another blog post.

So whenever I see a specification or a proposition, I do my best to make sure it is crystal clear to the reader (whoever the intended audience is) how the proposed functionality will make our customers more money or save money or make our solution more compelling.

Common sense methodology (not Agile)

Oleg Vishnepolsky, Global CTO at DailyMail Online and Metro.co.uk, writes Agile does NOT work.

It's obviously a bit of rant, but he lists some issues that Agile struggles with:

1. Short-term thinking that results from following short iterations and daily stand-ups
2. Architecture that often times can not be deployed piecemeal
3. Complex infrastructure in production that is supposedly continuously getting deployed over. If you are Facebook, you can afford automation. Can you ?

From Product Manager to CEO

We know that the Product Manager is sometimes labelled the CEO of the Product. It's not the best definition, in my opinion, but I have become interested in the similarities between the role of the Product Manager and that of the CEO.

Warning: As one of the founders of the Cambridge Product Management Network, I'd love to find a speaker on this topic!

What's the difference?
Gregg Johnson was a Product Manager for 10 years and moved to Product Marketing at Salesforce and then joined Invoca as CEO. He comments that "product management is a great training ground for becoming a CEO. The very nature of the PM role requires building the skills you need to be a successful executive" in this article Want to Be a Great CEO? Be a Great Product Manager First.

Here's a summary of his reasoning:

1. Create a compelling vision for your teams and company
2. Make the hard investment decisions.
3. Navigate between the 30-day and three-year levels.

I can summarise (1) & (3) as translation  - translation based on your audience: your conversation to a developer is different to that with a sales guy, which is different to that with a customer or a partner.

But even each one of those conversations has a time consideration: if you're talking to customer in pre-sales, then you want to discuss the business benefits of your current solution. If you're inviting an existing customer to participate in your beta programme, then you'll be laying your vision for the future and how your product in beta is an important building block for the future.


McKinsey in this article Product managers for the digital world list  Sundar Pichai, Satya Nadella, and Marissa Mayer as product managers and are now CEO to Google, Microsoft and (recently departed) Yahoo!

What’s more, product management is emerging as the new training ground for future tech CEOs.

McKinsey  reports that there are 3 types of 'mini-CEO' product managers in Silicon Valley:

1. Technologist
2. Generalist
3. Business-orientated

McKinsey insightfully states:

Any critic of the analogy between product managers and CEOs will point out that product managers lack direct profit-and-loss responsibilities and armies of direct reports, so it is critical for product managers with ambitions for the C-suite to move into general management to broaden their experience.

Generally true!

Software Internationalisation & Localisation

My first job out of university translating software from English to French. In theory, globalisation of the software had already been done (ie making the software being able to support more than one language) and all was needed was localisation (the actual translation from English into the local language).

Needless to say that globalisation wasn't done perfectly. During testing, it was discovered that the additional language meant that all store orders were doubled, for example.

One of the UI designers for Dropbox, writes the following advice in Design for internationalization:

1. Leave room for longer translations
2. Avoid putting text in narrow columns
3. Don’t embed text in images
4. Don’t create sentences with UI elements
5. Watch out for metaphors
6. Use descriptive feature names
7. Provide alternates for translation

Even big companies mess up. The translation of ebay's site struggled. In the violation of number 4 above the phrase "10h left" in the auction, then left was translated as a direction - oops!

Product Management analogies with American Football

Pragmatic Marketing interviews Neil Baron, lifelong New England Patriots fan and founder of Baron Strategic Partners in their podcast series.

Neil draws parallels with the scripted plays in American football and the instructions embedded in an orchestral score.

There are some great analogies:

• Product Management or Product Marketing orchestrate the play for the rest of the organisation
• Effective PM are the quarter back of the organisation to execute strategic role for the organisation, but don't be the water boy /girl that is waiting for others to tell them what to do, when to run onto the field and play a relative minor role.  (Approx at 24:30mins)

Conclusion: Be proactive or else you'll be reactive (like a water boy!)

Product Launch vs Release vs General Availability vs Deployment

These terms are tossed around with gay abandon and, as a result, cause some confusion, particularly in the minds of Sales and Marketing folks.

Here are my definitions:

Product Release	This is when the product has ready to be deployed. For Development (ie Engineering and Testing), their task is complete and they can roll onto the next development cycle.
Product Launch	Product Launch is a marketing announcement. This is the bright lights, drums, trumpets and dancing elephants moment. This is when you want the market or your customer base to know about your new release and to seed your lead generation process
Product Availability or General Availability (or GA)	This is when a customer can use the product.
Product Deployment	This is when it is activated for the customer. Whether a particular release is actually given to anyone or deployed is a decision made by Product Management, not of Development. Agile + continuous deployment means that this decision can be so implemented that it may by-pass Product Management, if due process is weak.
Pre-release	This is a term that is used in two scenarios I think: a) By sales to demonstrate new capability, but to set expectations that this product isn't quite ready for use, but available for demonstration (ie for customer consideration of adoption).< b) By product management to encourage potential beta customers to step forward as beta candidates

Some nuances

There is a difference between GA and Product Deployment is when a B2B vendor needs to ask permission from the customer before the software can be deployed or activated. For example, the new functionality may require the customer to do something (eg all users might have to log off or there might be down time) or the customer's staff may need training or the deployment might need to fit around the business cycle of the customer's environment (eg ecommerce customers dislike new functionality or surprises during the Christmas season for example).


A product may be announced before it's available. This is done to seed the market & to generate enquiries into the sales team. It may be done to spoil the market - eg pre-announce functionality to steal the limelight so that you look like a thought leader and competitors appear to be second to market. Big SaaS providers (think of Salesforce for example) forward announce deployments and their release dates in order to seed their ecosystem of customers and partners with this news.

A product may be announced after it's been available and deployed to beta customers - this allows for the generation of success stories in order to encourage adoption either by the existing customer base or to generate confidence & interest from prospects.

In B2C products, product release = product deployment

Apple famously make Product Announcements on one day with GA on the next day globally. This requires incredible planning (and draconian secrecy) to implement effectively. This can do this because Apple provide single-vendor products - they don't have complex ecosystem of 3rd parties around them (in general). Their secrecy about their product releases is legendary. Indeed, the tech press have taken to tracking shipping consignments from Foxconn factories in the Far East to California to guess product ship dates!

After all, customers don’t really care about releases; they care about availability. Sales and marketing folks don’t care about releases; they care about launches.

Launches must be aligned with the rhythms of your market, not the rhythms of your internal teams. Product marketers should align availability with customer demand.

You can do limited availability any time of the year but broad adoption takes place when the market is ready, not when development is ready.

The mighty Steve Johnson (formerly of Pragmatic Marketing) writes on this topic: Why a release isn't a launch

We're "post-agile" - it's official

Phew, I've been saying that the software world is distancing itself from pure Agile and saying we're now "post -Agile" and I'm glad to see others are saying the same: Post-Agile: A Design Thinking Approach to Software Development

There's even a blog on the topic: http://postagilist.wordpress.com

Here's a scathing view of Agile: Agile is Dead plus an excellent webinar from Steve Johnson (via Product Focus): Is Agile breaking Product Management?

What a product manager does on the first day, week, month, quarter

In conjunction with Product Focus, here's an infographic outlining what a new Product Manager should do in their first 90 days.

Download the PDF from Product Focus' website.

The raw task list was created as a result of meeting of the Cambridge Product Management Network. Then together, I and Ian Lunn from Product Focus converted the task list into an useful infographic for every product manager starting their new role.

Behind every great product

The article, 'Behind Every Great Product' is a classic text (PDF), first written in 2005, on Product Management by Marty Cagan. Marty has held senior product positions at Hewlett-Packard, Netscape Communications, America Online, and eBay. (More about Marty)

I set aside some time to read this on a journey some time ago.

It's littered with great insight and quotes about Product Management and  Product Managers.

A good product manager is responsible for defining the right product at the right time

The product needs to have the right features for the right market, and must be able to be executed with the technology  available in the required market window.

It is easy to define fantastic products that can’t be built, or at least can’t be built profitably or in the necessary timeframe. It is equally easy to define products that can be built profitably but which are not compelling to the customer.

The art of product management is to combine a deep understanding of your target customer’s needs and desires with the capabilities of your engineering team and the technologies they have to work with in order to come up with a product definition that is both compelling and achievable.

The process of coming up with the right product/right time boils down to insight, judgement, and the ability to make choices.

Manages Product Not People …. leading, but not managing, the extended product team.

In good companies, executives tend to be smart, experienced, and articulate -- that's why they are executives. As a result, it's easy to assume that they have superior judgement and should set the strategic direction for your product. This is a bad assumption. Executives can be excellent at verifying that a strategy is sound or suggesting interesting ideas, but not necessarily well equipped to set the strategy for a particular product. Executives lack the deep knowledge of the market, competition, technology, customer base and team that is necessary to chart a successful product course.

The ideal product manager does not necessarily have to come from your target market (there are pros and cons to this), but they absolutely need to be able to empathize with that target market. This trait is often difficult to find in high-technology companies trying to produce mass market products.

Deloitte's UK Mobile Consumer Survey 2016

Deloitte's publication of its mobile phone survey has plenty of interesting stats. Here are some that caught my eye:

• 4G adoption has more than doubled in the last year, from 25% to 54%.
• 31% of smartphone users make no traditional voice calls in a given week. This contrasts with a quarter in 2015, and just 4% in 2012. The substitutes are text messaging, instant messaging and social networks.
• The majority of survey participants have downloaded 20 or fewer apps.
• Smartphone penetration in the UK leapt from 52% to 81% of the population in the four years to May 2016, but further penetration is anticipated to slow to 2-4% in the next 12 months.

Transparent cookie policy shows the privacy madness in Ad-tech

I went to Reuters UK website and, in clicking on their cookie policy, I was presented with this screen. See their advertising guidelines and click on the Cookie Consent button in the bottom right hand corner.

Well done to Reuters for demonstrating the transparency of how all the cookies on their site are being used.

But what a hideous user experience / privacy experience!

I clicked on the two 'All off' buttons to stop cookies being fired (hopefully??) and data being collected about me and my browsing habits (even more hopefully???). This is the next screen - the battle isn't over yet!!

I closed my browser window and got my news from another source - like the ad-free BBC.

Having worked in Ad-tech for the last 2 years, I've been on publishers' side of the fence on this issue (indeed Reuters was a customer of my previous employer, Grapeshot), but this is a truly frightening user experience for the average internet user. No wonder ad-blocking is rising at such a rate (See Wikipedia entry for Ad Blocking)

I'd be fascinated to see how many people actually manage their cookies using this screen or how many close down the page and go elsewhere - as I did!

More Product Management Mistakes (from Rich Mironov)

Rich Mironov, a product management expert, lists some of the mistakes that a new product manager might make in the first 6 months. I summarise them here, but go to the article for the details:

1. Promise a new feature to a customer without running it past your team.
2. Generalize your first three customer interviews into a market segment.
3. Confuse sales calls with customer learning/research
4. Believe your own marketing/selling materials about why customers use and love your product
5. Announce that you’re "CEO of the product"
6. Tell engineers how to solve a technical problem
7. Postpone meeting your internal counterparts
8. Confuse process steps (stories, tickets, releases) with market success (renewals, revenue, customer love)

Also take a look at 'What a Product Manager does on the first day / week / month / quarter in their new role' - a session that we have run at the Cambridge Product Management Network a couple of times.

Product Management Mistakes

From June session of the meetup of The Product Group London

Some of the mistakes discussed:

1. Confusing Customer Requirements with Product Requirements
2. Confusing yourself with your customer
3. Confusing the Customer with the User
4. Confusing Features with Benefits
5. Confusing Building the Right product with Building the Product Right
6. Confusing Good Product with Good Business Model
7. Confusing Inspiring features with Nice to have features
8. Confusing Adding Features with Improving products
9. Confusing Complete Product with Sellable Product
10. Confusing Product Launch with Success

Jobs to be done

Clayton Christensen (of Innovator's Dilemma fame and one of my management heroes) writes in the September edition of Harvard Business Review about understanding customers intentions (see Know Your Customers’ "Jobs to Be Done" - free too!).

Two great paragraphs:

The fundamental problem is, most of the masses of customer data companies create is structured to show correlations: This customer looks like that one, or 68% of customers say they prefer version A to version B. While it’s exciting to find patterns in the numbers, they don’t mean that one thing actually caused another. And though it’s no surprise that correlation isn’t causality, we suspect that most managers have grown comfortable basing decisions on correlations.

After decades of watching great companies fail, we’ve come to the conclusion that the focus on correlation—and on knowing more and more about customers—is taking firms in the wrong direction. What they really need to home in on is the progress that the customer is trying to make in a given circumstance—what the customer hopes to accomplish. This is what we’ve come to call the job to be done.

In conclusion, here's his argument as to why big data only is the second tool to reach for. The first thing is to understand the desires and intentions of your customers.

Many organizations have unwittingly designed innovation processes that produce inconsistent and disappointing outcomes. They spend time and money compiling data-rich models that make them masters of description but failures at prediction. But firms don’t have to continue down that path. Innovation can be far more predictable—and far more profitable—if you start by identifying jobs that customers are struggling to get done. Without that lens, you’re doomed to hit-or-miss innovation. With it, you can leave relying on luck to your competitors.

Bravo - I'd rather rely on understanding and insight than data.

Which is faster: Waterfall or Agile?

To be clear, my personal position from the arrival of Agile a decade ago has been of scepticism rather than love-at-first sight. Agile's star couldn't be higher 5 years ago. If you weren't Agile then you were a dinosaur.

Fashion has quite clearly moved from Agile only to Water-Scrum-Fall. (Gone are the days (TG!) that starry-eyed developers would come back from Agile training courses wanting Marketing or Sales to go Agile too!)

Credit: iQuest Group 

Let's rewind at the outset: both Waterfall and Agile share exactly the same objectives: to deliver high quality products as quickly as possible to a willing market. Both have strengths and weaknesses, but the inappropriate application of the letter of the law in either case leads to its relative weakness.

On Agile

Agile does produce more recognizable product more quickly, but must be inefficient because:

• Making lots of software releases generates an overhead: for development, testing, deployment, customer communications, for customers themselves. 
• Gathering and analyzing customer feedback (which is so important to Agile) can be difficult and time consuming. (It is certainly expensive to set up and configure in order that this process isn't too arduous). Note that Engineering only does some of these tasks.

Agile's strength is that it doesn't do too much before all the parts in the workshop floor are re-assembled together and the product is shippable. (There is the theory that less development needs less testing, but in complex software, a small error can have massive consequences.)

Agile's weakness is that tends to encourage a horizon of a two or three sprints only. Estimating epics which span multiple sprints, can be even harder / more error prone than Waterfall.

Also there is fallacy at the bottom of Agile: that all resources are interchangeable. This is wrong: people develop specialisations or area of responsibility. This expertise can easily generate a bottleneck and tasks requiring a critical skill always end up on the critical path - not just for one project, but the problem appears to snowball, impacting multiple projects.

On Waterfall

Waterfall does mandate careful attention at the outset to scope of the product. This discipline (call it product planning or roadmapping) is considerably downgraded in Agile - which is a huge mistake. Many execs believe that once they have a product owner (who writes user stories and manage the sprint process), then they don't need product managers (who assess product concept, write epics & launch products).

Waterfall's strength (in terms of speed to delivery) is that it smashes the problem into little bits all over the workshop with the final deliverable in mind and only intends to reassemble all the bits at the end. Continual reassembly must be more time consuming to get to the same objective. Agilists will rightly point out that the objective invariably changes and that remembering how to reassemble all the
bits is error prone, requiring lots of testing.

Waterfall's inherent weakness is that because the endeavour is so carefully planned at the outset, then everyone follows the project plan, heads down in the sand. What a good product manager should be doing is constantly scanning for changes in the market place, in the requirements, in the deliverables. He or she should be constantly 'checking in' with all parties to ensure that any new information is gathered / digested / understood and its impact assessed.

Conclusion

As in life, it is a compromise. However, time spent in reconnaissance before a line of code is written is rarely wasted. And that's why I like Water-Scrum-Fall.

Some references

• Agile is for development only (previous blog post)
• Agile vs Waterfall (from Udemy)
• First mention of Water-Scrum-Fall in 2011: Water-Scrum-fall is the reality of agile