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

Agile is for Development ONLY

280 Group has written an excellent article about the merits of Agile.

Agile is great for development, but has done a lot of damage for those doing Product Management. Those that know me, know that I am a massive sceptic of pure Agile champions.

I have summarised the article, but I encourage you to read it yourself: Agile is Not a Business Process:

• Agile software development has transformed how we approach software product development, and has delivered some enormous benefits for efficiently delivering software products to the market.

• The only planning described in The Scrum Guide is a planning meeting led by the Product Owner at the beginning of each sprint to determine the sprint objective and which user stories from the ordered backlog should be worked on in that sprint to achieve that objective.

• Based upon this guidance, a common interpretation by too many companies is that they only need a Product Owner and that the only planning required is the planning done at the beginning of each sprint, which, in my opinion, has relegated Product Management to a very tactical role of “helping the development team” by writing using stories and acceptance criteria, working issues with the development team, testing user stories and maintaining the product backlog.

• Agile development only addresses one phase of the lifecycle methodology

• Product Management is responsible for “achieving business outcomes”, which entails a lot more than optimizing the value of the work done by the development team.

• if in your role as a Product Manager, Agile has sucked you into the development process, it’s time to take a step back and understand that your role is more than just maximizing the efforts of the development team, but it’s to achieve business outcomes, and that requires you to manage your product through the full lifecycle based upon your market expertise and a well-defined strategy.

Remember, Agile is a Development Practice, Product Management is a Business Practice.

Where should a product manager spend their time

Excellent insight from an expert product manager, Gerrit Vermeire who is Director of Product Management at Barco.

“I want to absolutely avoid product managers acting as an expert helpdesk i.e. doing things other people or proper documentation can handle. They should focus on the things nobody else will do if they don’t – such as defining the overall mid and long term strategy, creating the big picture, understanding the market problems and translating them into solutions and products on our roadmap. I want to drive the bulk of my product managers’ workload into the ‘fuzzy front-end’ – as shown in the picture. These are the more strategic activities of generating ideas, understanding what customers want, finding out what can be built and what could be commercially successful.”

Also Gerrit comments on managing a portfolio with multiple product managers

“If I make product managers fully responsible for a too limited set of products in the portfolio there is a danger they don’t see the big picture. Similarly if we split things by current and next generation or pre and post launch, we don’t get continuity through the whole life-cycle and risk missing a lot of key information.”
“What does work well is to off-load some product management activities to a separate product marketing team. They know their vertical markets well and drive the sales enablement activities during product launch. They have the insight to know which customers are best to talk to and can focus on managing the relationship. My product managers can turn up to customer meetings with new product ideas and get great customer feedback.”

Do read the rest of the article on ProductFocus website.

The value of an external Product Management Consultant

Many companies recognise that they have a requirement for Product Manager. However, for some companies, they have muddled along without one but know privately that it remains an Achilles heel.

This may be passable on a day-to-day basis, but to build a long term roadmap or to make a step it is sorely lacking some expertise.

There is a perception trap here: some organisations don't really grasp what the product manager does and so underestimate the scope of the role, so can't justify a full time role.

Recently, I have been talking to organisations about part-time / interim Product Management – and particularly the value that an external product management consultant brings.

What an external consultant does NOT bring

• Intimate knowledge of the technology
• Intimate knowledge of the product and service
• Intimate knowledge of the market

These factors may, to some, to be crippling reasons as to why an interim product manager or a short term consultant may not be able to provide enough value. But this is incorrect – these very reasons provide tremendous value.

Advantages of an independent consultant

• Objectivity An external consultant can be dispassionate about origin of products, their history, the processes or the people behind it. This person can look objectively at the products / product portfolio / product processes at that point in time and provide an unbiased perspective without the burden of historical baggage.
• Independence An external consultant is equally unknown to all the organisation - therefore that person has no 'pet' interests, favouritism or bias.
• Ignorance of the Product and the Market An external consultant is unlikely to know the intricacies of the the product or the market - and cannot hope to (in comparison to the expertise of the existing staff). Therefore, the important (but sometimes overlooked) statements of product differentiation, market characteristics, competitive analysis and product-market fit have to be clearly articulated. 
• Better Decision Frameworks The external consultant should bring toolkit of analytical and decision frameworks that map analysis and research, leading to transparent and justifiable decisions. In my experience, once complete, it is rapidly realised that the product positioning and collateral is missing half of the value proposition.
• Best Practice from other industries / sectors An external consultant should bring a wealth of experience learnt elsewhere on alternative business / revenue models, partner relations, go-to-market techniques, pricing strategies etc.

How to get the best out of a Product Management consultant

Interim Product Management consultants do need to be contracted / engaged properly in order to define boundaries for both side. There are several modes:

• Time based (ie per diem)
• Capped (ie we'd like up to x hours / days of your time)
• Please complete this task by this date (eg hit a release date)
• Objective based
• Task based

Projects that suit an external Product Management consultant

External product management consultants are best at the following tasks:

Product Management

• Competitive Analysis
• Product Portfolio Analysis 
• see this excellent session on Portfolio Management given by Richard Jones to the Cambridge Product Management Network
• Product Testing & Review: 
• External product testing, user experience, review of product literature (eg help documentation, training materials etc) and positioning

Product – Market fit

• Product Roadmapping – see my presentation on Seven Rules of Product Roadmaps
• Pricing Analysis
• Release Management – a dispassionate expert to steer a product towards release, during a stressful and critical period. See case study on CDK Global for my role as Release Manager.

Product Marketing

These types of tasks usually become part of the second phase of a product management project:

• Sales and Marketing literature review eg collaterals, external website, sales training, sales tools

Development Processes and Tools review

• Again, these is often a phase two of a review, because the existing processes and tools have supported the existing status quo which has been identified as being unsatisfactory.
• These endeavours are heavily operational and become difficult to generalise, but often these projects revolve around information / data collection and analysis to support decision making or information sharing – particularly to the sales and operational teams.

“Hold-the-Fort” Interim Product Management

Many companies leave the product manager role vacant for ages whilst they recruit the perfect candidate. Again, indecision / lack of consensus / strategic flip-flop may cause no end of pain.


‘Hoping’ that you’ll muddle through with your existing processes is well.... muddling. Does the investment in your development deserve a muddled product management approach?

The cost of not using a Interim Product Manager

If the organisation has decided you need a Product Manager then it is already 4 months too late. Any recruit spends 4 months playing catch-up with all the Product Management debt, so the company is waiting months and months before the Product Management function is actually leading the business forward.

When the permanent recruit comes on board, he or she is immediately deluged with a series of crises or burning issues. Their head immediately dives into the here and now, fighting fires and making snap decisions without a good understanding of context or history. This is an unpleasant start and most probably not what the new recruit was promised at interview.

With 4 months of no product management, each division of the business has already set off on its own journey of product management decision-making (ie they make decisions that are optimized to their own agendas, not those of the market), which makes steering the troops back on course towards a transparent set of objectives VERY difficult….. if not too difficult to contemplate.

Advantages of Hiring an Interim Product Manager

• Product Management won't judder to a halt. Maintaining the discipline of Product Management will continue on and it won't cave in leaving the organisation to the ravages of a free-for-all.
• New and refreshing thought process
• Like all consultants, because they don't have the vested interest in the short term, they can look objectively at the long term.
• The Bridging Product Manager can accelerate the onboarding process for new recruit. The new hire won’t be overwhelmed by a crisis situation and / or an overflowing issues list and / or a host of people grinding themselves against each other.

See Also

See this article from the 280 Group: Don’t Let Your Product Fail While You’re Recruiting for a Product Manager.

For assistance with your Product Management 

Please contact me.

Characteristics of a superb Product Manager

Product Focus authored this excellent blog post on the ingredients of an excellent Product Manager. Here's their initial suggestions:

1. Passion 
2. Great at networking 
3. Thinks big 
4. Accountable 
5. Able to focus 
6. Delivers 
7. Expert compromiser 
8. Good communicator 

The post and the comments underneath are well worth a read.

The additional attributes that have been suggested that I like are:

1. Understand and can explain their basic product economics / Commercial Nouse
2. Can bring teams together - I think this is a complimentary skill to 2. Great at Networking
3. Causality / Insightful
4. Knows their market / customers
5. Bounce-back-ability

This list is interesting to compare with Product Management interview questions from Ken Norton.