Perhaps the most important challenge when considering a consumption pricing model is to align the use metric to the value the customer derives from your solution, which can evolve over time.
17 May, 2021
12 May, 2021
10 March, 2021
But Mind the Gap. In many companies, the focus is on Agile and Product Owners, and the strategic & leadership role of product management is missing
Possible extension to the infographic - 'Ticket to Ride'
- Business Savvy
- Communication skills: listening and clarity in written and vocal transmission
- 'Spidey' sense of what's doing to happen next
- Leadership (vision and direction) and Trust
02 March, 2021
1. A customer base littered with bespoke deals.
The main problem usually encountered is that there isn't (much of) a discounting policy or it isn't adhered to. When I worked at NeuStar, there was a solid discounting policy AND a robust methodology to go beyond it.
"Special deals" had to be approved not by sales management, but by the product board. This mechanism really did account for the revenue / cost / profitability for the whole customer lifecycle.
2. Purchase options that include unlimited, or “all-you-can-eat” use.
Hmm, unlimited deals should be used when the value of the propositions is too complex for the customer and the vendor to justify, but everyone knows there's significant value. Within reason, as long as costs / burden don't torpedo profit margins, it is entirely valid.
Obviously, it is easier to make this decision when the variable cost of more consumption is tiny.
Fair use policies (whether formal or informal) need to be implemented so that costly abuse of unlimited can be contained. For example, 'burst usage' when greater utilisation is permitted but within reason (eg to a limit or within a period).
3. Prices that don’t account for customers’ varied budget cycles.
Simple statement, but the ripple back of this issue can be massive.
Let's say your customers get paid on a project-basis ie on completion of milestones. As a customer, you'd like to pay your suppliers when you get paid. As a vendor, if income can be guaranteed, this may be acceptable.
If however, the revenue is exposed to risk, this may not be acceptable to either party. For example, the construction industry is prone to delays or changes. As a concrete vendor, payment on project completion is unlikely to be acceptable.
In the software sector, does this change how your product is priced (yes!) or delivered (likely) or built (possibly)?
4. Enacting pricing changes without modeling the impact on legacy and net new revenues.
Oh, SO important!
A company releases a new product version that is supposed to cannibalise the existing product. They anticipate that all existing customers will diligently glide over to the new product without churn.
Oh, how wrong! Any change in product or pricing can lead to re-evaluation of the proposition and the possibility of churn. Please see my work for CDK Global for exactly this problem/
5. Complex or confusing pricing
Value-based pricing is great in theory, but if your product has multiple and diverse use cases, then the complexity of pricing appropriately becomes far too difficult to support. As a result of the practical decision to simplify pricing models, your target market may be sliced to a smaller size – never a palatable proposition, but sometimes mandatory to simplify all sorts of problems, not just in sales, but in product development and delivery and branding.
26 October, 2020
A friend pointed me to How to crack product metric questions in PM interviews. In essence, it discusses how does a service provider respond to a change in a metric or KPI (Key Performance Indicator).
A definition from the article:
Metric interview questions test if candidates can perform data analysis and select key metrics that matter most to the success of a product. Employers like Facebook and Google use these questions to evaluate critical thinking and communication skills.
There are two types of metric questions - one builds on the other
|Metric definition questions||Metric change questions|
Solving the Metric definition question
The article recommends the use the GAME method
Solving the Metric Change question
The article provides its own methodology.
|Define the metric change||Make sure you fully understand the metric that is being presented
|Explore possible root-causes of the change||Use the MECE
|Conclude||Make sure there aren't any horrible assumptions that you haven't validated / eliminated.|
* For info on MECE:
Escalation and Communication
The article hardly touches on the critical, critical
point of issue escalation and communication.
After you have done your initial assessment, you need to answer the question: Do I ring the alarm bell and to whom?
Judgement call: Let's assume that (a) the metric isn't a false positive and you've validated to some significant extent (b) the metric matters. So, how high do you escalate the issue?
Factors to consider:
- How many other business functions are impacted by the incident?
- Is that metric important to them?
- Can they do something about it, either to resolve it (eg some root-cause analysis) or to reconfigure their business function to accommodate the impact of the incident?
I recommend using this yard stick:
|Level of concern||Action|
|Not a concern or quickly solved and implemented||
|Somewhat concerning, but impact is contained||
The importance of communicating - and re-communicating
As soon as you communicate outside of your team, make sure that someone
is knowingly and consistently appointed as Incident Manager (ie it could
be you!). Note that if the problem rattles on, then you may need to
appoint a Communications Manager in front of the Incident Manager to
protect the Incident Manager from simply responding to communication
enquiries rather than actually working on the resolution.
It's best also to alert other business functions how you will update them on progress and frequency of updates (even if there is no progress).
Use of incident support tools
There is a great danger in over-engineering the use of incident support
tools. Over-engineering = it is too clumsy or laborious at the point of
the crisis. If others aren't familiar with the tools, then they will still
ask for email / telephone / instant messenger updates anyway!
Next step: Deep Dive into Root-Cause Analysis
Once you have done your initial assessment and then communicated your initial findings to relevant business function, it's time to dive deep to separate symptoms from root-cause. You may need access to multiple test and near-production systems(*) to validate theories.So do make sure these are functional before the crisis hits.
Do ask around your team (DevOps, Release Management, Testing,
Engineering) for their input into symptoms and route cause. In many
circumstances, something similar has been seen before.
Cycle back with colleagues and partners based on status and resolution - instant messenger is fab here!
(*) Near-production = an environment that mostly closely replicates your live or production environment
There may be several resolutions available: there's a matrix of time horizon vs cost-benefit.
Multiple resolutions might be appropriate - and that's absolutely appropriate to pursue several simultaneously. eg roll-back recent enhancement; test proposed partial fix; kick back to engineering for a rework with new testing scenarios etc.
12 June, 2020
Steve Johnson, one of the respected voices in Product Management, cleans up some of the confusion about product roles and titles in Product Management. He admits that he (like me) is fan of the “product management triad” - a product or portfolio team responsible for strategic planning, release planning, and launch planning. Here's the link to the particular post and full description of these roles.
|Product Strategy Manager||Future||Evaluates and prioritizes future products and the portfolio|
|Product Owner1||Next||Focuses on what’s next in terms of features and product options|
|Product Marketing Manager2||Now||Focuses on products that are currently available
1 Steve prefers Product Planning Manager - yuk!
2 Steve prefers Product Growth Manager - yuk!
I do like the time box approach to the focus of each of these roles. Of course, this is simplified. It's not as if the Product Strategy Manager slurps espressos all day and pays no attention to the last quarter's sales figures or the Product Marketing Manager isn't constantly assessing the competition's capabilities and figuring out how to 'out-product' their offerings.
I would also recommend studying this Product Taxonomy from Product Focus (providers of product management training and resources - and one of the sponsors of the Cambridge Product Management Network).
Here's my take on 'Who owns what' which dovetails with Product Strategy vs Product Owner vs Product Marketing
Portfolio - owned by Product Strategy Manager
Responsible for managing the portfolio. He / She isn't the only decision maker. This is best managed by Product Investment Committee - this is a beast in its own right - but this has representation from Sales, Marketing, Product, Engineering, Research plus some financial modelling expertise.
The Strategy Manager often takes on the long-term management of the core platform, as moving the platform forward requires care and evaluation, because key decisions may negatively impact capability of the products that are built on top of the core platform. ie mods to the core platform are expensive and time-consuming to get right.
Propositions - owned by Product Marketing
This is the realm of product marketing. Product Strategy may be involved if there is cross-subsidisation of prices between products (or product lines) and platforms.
This area gets super complicated when propositions vary between countries / region of the world. Different countries may provide functionality for free (or charge for free functionality!) for a whole variety of valid reasons (local commercial agreements, tax or legal reasons, history & politics, how core product development costs are charged to territories). This is matter is worthy of another blog post or even a book!
Products - owned by Product Owners
When considered in a portfolio, this is the domain of product owners or,
if the product is significant enough, a manager in their own right.
19 May, 2020
CEO mutters that maybe it is time to hire a product manager.
Everyone else wonders, "Err, and how will they help?" And they get that
uneasy feeling that the company is going to be less fun and more
restrictive and more "NO!" Perhaps the first publication of the Employee
Handbook had the same reaction - mildly menacing, but necessary for some
(other) slightly dysfunctional part of the business, but not
Below I augment the great story that Product Focus (a well-regarded provider of product management training) tell in their Product Leadership Workshops and, to some extent, is outlined in their publication, "What is the point of Product Management?"
Here's the history of a B2B software company and the welcome emergence of product management.
The small company was founded on technical innovation and good customer service to its early customers. Initial Product Management is executed by the CEO. The company continues to thrive, and the CEO's time gets further and further sub-divided, but the technology and the product remain his/her passion.
But a new Sales Director joins the company and complains, "We’re a technical-led company. We need to become customer-driven." And that sounded fine except every new contract required custom work. Contracts were signed with a dozen clients from a dozen market segments. Soon the costs to support all these different products started to escalate. The latest customer’s voice always dominated the product plans. The CEO concludes that “customer-driven” meant “being driven by the latest customer”, and this created short-termism to the frustration of Engineering with the creation of massive technical debt and the sense of favouritism towards particular Sales team(s) creating lots of subversive backdoors to decision-makers. The price list becomes a joke, as the Sales team somehow manages to get colossal discounts on big deals using the mantra of 'a strategic customer deal,' without regard to profit margin.
When a board member declares, “We’ve become a sales-led company. We really need to start being market-driven,” a brand specialist is head-hunted away from a big consumer product company to be your VP of Marketing. As part of a re-branding initiative, she designs a new corporate logo with a new colour scheme for the web site, new collateral, and an updated trade show booth and a big expense budget for conferences. Hundreds of thousands of dollars are spent without any change in revenue.
Soon the CFO whispers to the CEO, “Don’t you think it’s time we started controlling costs?” So, the company becomes cost-driven and started cutting out all the luxuries like travel, technical support, bonuses, and employee appreciation. Everything had to be justified with a business case and the CFO was tough on any assumptions – the only things that got past him were small evolutions of existing products. Account management was lauded for winning incremental business, usually with small but exotic customisations which started to build technical debt and make upgrades to new product releases more and more painful. And, innovation stalls, engineering resignations escalates!
At this point, when Finance has gone too far, margins have suffered, and the future product pipeline looks thin and also-ran. The CEO steps back in and is sorely tempted to take the company back to its technology roots but he/she knows that this needs to be tempered with supporting existing customers and protecting existing revenue streams. So, a new, hybrid approach is required – so the company recruits a product manager.
The CTO and the Head of Engineering welcome the idea. Finally, the Product Manager is the go-to person to make sure his/her team build the right stuff and have a solid, defensible product strategy. This prevents his team/technology from being yanked around all the time OR working on the latest, crazy C-suite initiatives OR brainless product customisations for the big customers, that don't make sense and will become a mill stone around the neck of Customer Support in the future.
But the Head of Sales is also keen. Her team can’t answer the tough questions customers are asking. Finally, someone with lots of product expertise can answer technical questions without murdering customers currently in pre-sales with infinite complexities and CLOSE SALES! The perfect PM should answer customer RFPs (Request for Proposals); AND come out on sales trips whenever they’re needed; AND be the demo jockey; AND talk authoritatively about future product releases and when they will occur. They should also be able to write some technical whitepapers and do some decent competitive analysis.
Marketing, who if you’ll remember lost a lot of credibility with their splurge on branding, are also having problems with their collateral. Their vague product brochures and website content don’t seem to hold customers' interest and come in for a lot of criticism from prospects and internally. The Product Manager can explain the product once and for all, providing decent product messaging and propositions for the collateral. A product roadmap with some realistic dates would allow her to plan marketing spend, rather than a knee-jerk reaction to product releases or to cancel events sponsorship at the last minute due to another slippage in the product release date.
Finance is relieved to hear about Product Management arriving. Finally, there’ll be someone to hold accountable for whether each product is making any money. The CFO immediately starts working on a new, complex, business case spreadsheet that the Product Manager will be tasked with completing and comes up with detailed KPIs that the new product managers will measure for him!
By this stage, Account Management & Customer Support have almost lost the will to live. Every day, they writhe in agony trying to solve exotic customer problems which Testing and Engineering struggle to recreate, never mind solve. They see the new Product Management team as the last hope to solve the Sales madness of selling solutions that are further away from the core product offering and hanging Customer Support out to dry AGAIN. Otherwise, they are definitely throwing in the towel and quitting.
Everyone has their view of what the perfect product manager should be
doing – it’s helping them do their job! In
truth, Product Management should be greasing the wheels of all these business
functions because they put the product's holistic success at the centre of what
A Product Manager who enjoys taking new technologies and concepts to market. Fascinated by software, internet and mobile sectors. Start-up and scale-up specialist. Based in Cambridge, UK. For more information, see www.stream121.com.
11 May, 2020
In a previous post, I looked at the Product Management & Product Marketing model that Redgate Software (a local Cambridge-based company) uses. In it, I identified a component, that didn't appear to be addressed: beta programmes.
- In the UK, it is pronounced 'Bee-ta'.
- In the US, it is pronounced 'Bay-ta'
What is the purpose of a beta programme?
The build team (Engineering, Testing, Product Management, Implementation, Technical Support) want the beta programme to technically validate the latest functionality - that it works outside the lab, in real customers hands and that bugs are flushed out and those bugs are validated in subsequent releases. The end goal of a solid product should not be compromised by time constraints.
- Marketing and Product Marketing want a case study and a quote for the press release - as soon as possible please.
- Sales, Sales Engineering, the CFO wants a big name brand to do reference case study that ignites the sales pipeline - ASAP as well.
Why should a customer participate in a beta programme?I'm sure that we have all participated in these CBT (Customer-Based Testing) programmes at some point: buggy software whereby the customer does the testing - seemingly to the shocked surprise of the vendor. This can be immensely damaging to the beta programme, the provider’s brand, the relationship between participant and the provider.
And, for the customer, it's a darned good reason not to participate in a beta programme: too much effort for no advantage (or indeed negative advantage).
For this reason, providers need to ensure that, during the beta, they have the Engineering bandwidth to rapidly fix issues that are identified. This, of course, is difficult to estimate exactly how much resource is required, but essential that this remains top priority. Unfortunately, Engineering’s core capability of building beautiful, well thought-out functionality does not match the issue + investigation + quick response cycle of beta programmes – expertise that is embodied in Support or Professional Services.
Valid reasons for customers to participate in a beta programme are:
- Access to latest version - see later for my experience with CDK Global
- High-profile within the vendor's organisation: ie access to Technical resources or insight into the vendor's strategic intentions.
- Cost-reduction in fees, perhaps for a limited period
Which business functions should participate in Beta Programmes?There are many good and bad reasons why different parts of the organisation should participate in beta programmes.
Err, yeah, of course, but some customers have a different propensity towards beta programs.
Customer whales (ie big ticket customers) that that are currently in pre-sales should definitely not be part of a beta. It may destroy the sale altogether: experience with buggy software may leave a nasty impression in the mouth - even if it is exactly the functionality that they are begging for.
Getting a quote out of a whale's marketing department may take months, if at all.
Beta software is usually provided at a discount - possibly a significant discount - a discount which may never be recovered on full release and therefore full price - and too expensive a margin to surrender.
Existing customers are great for betas - they understand what the previous product does, users and the business buyer have a positive relationship with the beta provider. Technically and financially, the provider has been validated and approved. This certainly makes it easy to draw up a shortlist.
However, there may be enough 'baggage' in the account that existing customers may derail the beta at the outset. They may demand so-called 'fixes' (missing pieces of functionality that they perceive in the existing product) or their environment / use may not match the requirements of the beta functionality. They will want compensation for their participation - and this compensation may be more valuable for them then the business benefits of the beta software.
Some of the best beta programmes I have participated in have been with new business divisions of existing customers. Commercially an existing contract is easy to extend. The vendor sees new business and the customer has the assurance of existing proof elsewhere in their organisation.
New, NEW customers can also be really good. They genuinely behave like new customers.
They generally have more operational flexibility - they haven't honed their own processes to your product yet - and recognise that they need to create new processes.
Existing customers may say, "Yes, we'll be on your beta - as long as the product is "better" and nothing changes." Well, if the beta product aims to cannibalise the existing product, then the beta product will be "different" - better in many respects, but different in others. These differences may be negative enough to existing customers that they outweigh the new advantages.
The issue may be become more apparent if the existing customer is now off-centre from the target market with the new product. Existing customers may feel that they are being shoved to one side by the relentless progress of the vendor - and this may give the existing customer on the beta programme a sour taste in the mouth.
Another advantage of new customers is that the beta programme doesn't have to tiptoe around Account Management or Sales and get their buy-in.
Testing needs to valid the software on its way out and also to validate any issue as reported. For this reason, it is often essential that Testing has access to an environment that has beta code on it - let's call it pre-production - they are interested in isolating the real-world issues in a lab environment. Messing around with the production server is not to be recommended as it may create serious degradation to the service.
Well, yes, they created the software and they are responsible for delivering it and fixing it. They are critically interested in technical validation in real-world environmental.
If an existing customer is involved, the participation of Account Management (or Sales or Professional Services or whatever function manages existing relationships) is undoubtedly required, particularly at the start and end of the beta programme.
This function is compensated with incremental revenue - quite rightly, they don't want to jeopardise their account with the unknown. So, account management need reassurance that their customers' participation in the beta will help their account.
If the beta programme runs in parallel with existing product, then Account Management and Customer Support continue to support the existing in-life product. If the beta programme cannibalises the existing product, then the beta programme manages and supports the customer.
This function is generally wary of beta programmes, as it is often increases the amount of first-line call handling that they are required to do.
Implementation / Professional Services Team
The participation of ProServe is dependent on the amount of customisation required for the beta customers. Development would like 'vanilla' customers with the least customisation. However, this is dependent on the interest of the existing customer base in the beta programme and, with gritted teeth, the beta programme may be obliged to accept a highly customised account into the beta.
The great hope of vendors is that the new version fixes lots of issues in existing accounts - helping Account Management / Sales (unlocking new revenue), Professional Services (less implementation grief) and Customer Support (fewer issues and better relationship). And yes, it should leapfrog the competition and trample all others in the marketplace.
Special Cases - Saturated Markets
Newly all of my product experience has been in small scale-ups. However, I did have one fascinating experience working for CDK Global (see case study). As the Release Director, I was also involved with the Beta Programme - admittedly at arm's length.
CDK Global's product was the first major release in 12 years. It is worth mentioning because CDK Global dominated their market with 60%+ Total Ownership. Their customers (car dealers) operated in a highly competitive market and any new advantage could significantly tip the market. So, getting on CDK Global's beta programme could be a game changer in the short- and mid-term. When a slot on the beta programme was offered to a shortlist of existing customers, each place was eagerly snapped up.
ConclusionBeta Programmes are extremely important to software creation teams, but managing these diverse expectations can be equally difficult - particularly when the product launch (with all those expectations!) is dependent on it.
11 December, 2019
Their model (above) is based on the SiriusDecisions Product Marketing and Management Model which is reproduced below for ease of consumption as it is hidden behind a (free) registration wall (too much of an impediment for its value, IMHO).
Redgate's description is an improvement (much clearer and tighter in scope) where as SiriusDecisions diagram is more encompassing by slotting product in between marketing and sales.
Redgate's version shows the division of labour and where they work together.
Beta Programme ManagementThe only thing I see missing from Redgate's model is a beta programme management - which is referenced in SeriusDecisions model.
In my experience, the beta programme can be managed by either party, but best led by Product Marketing initially, who are closer to the customer. However, the lead may change in a small beta programmes, under three circumstances that I can think of:
- The beta programme is very technical in terms of functionality and requires of Engineering's expertise to implement or generate significant value OR
- The latest release uses novel technology which is 'sensitive' (shall we say!) or both the rest of the organisation and the customer don't understand OR
- The beta has significantly more technical issues than anticipated and effectively Engineering has to jump in and effectively resolve and effectively they run the show.
14 November, 2019
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.
08 October, 2019
- Proposition Development (eg Sales and Marketing)
- Technical Construction (ie Engineering)
- Value Realisation / Utility (eg User Experience, Implementation, Customer Support)
- Human 'Savvy' (ie awareness or sensibility)
- Corporate 'Savvy'
- Project and Process Management
04 October, 2019
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?".
11 July, 2019
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.
24 September, 2017
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:
This often leads to a conversation about sales qualification in general. Here's a mnemonic called SCOTSMAN from salesplusprofit.com:
- "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."
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.
16 August, 2017
It's obviously a bit of rant, but he lists some issues that Agile struggles with:
- Short-term thinking that results from following short iterations and daily stand-ups
- Architecture that often times can not be deployed piecemeal
- Complex infrastructure in production that is supposedly continuously getting deployed over. If you are Facebook, you can afford automation. Can you ?
17 July, 2017
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:
- Create a compelling vision for your teams and company
- Make the hard investment decisions.
- Navigate between the 30-day and three-year levels.
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.
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!
01 March, 2017
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:
- Leave room for longer translations
- Avoid putting text in narrow columns
- Don’t embed text in images
- Don’t create sentences with UI elements
- Watch out for metaphors
- Use descriptive feature names
- 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!
06 January, 2017
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!)
12 December, 2016
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 nuancesThere 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 deploymentApple 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.