Product Focus provides world class product management training courses, workshops and consultancy in London and throughout Europe. Read our product management blog for best practice, insights, tools and analysis from Europe’s leading product management experts.
Personally, we don’t mind the Hi.P.P.O. Sometimes we have to bow before the Hi.P.P.O. Sometimes we are the Hi.P.P.O.
What we truly fear is the Z.E.B.R.A (more on that below).
While the Hi.P.P.O is often rightly derided as a terrible decision making process, there are some situations where it’s actually a good thing. So here are 3 reasons why we might want to listen to the Hi.P.P.O.
1) Testing is Expensive
Sometimes, it’s just not worth it.
For Google, it makes a huge amount of sense to test 41 shades of blue. A fraction of a fraction of a 1% increase in conversions can means millions of dollars to google. For the typical startup? Not so much.
Google also has millions of page views and can detect statistical significance out of such small changes. Most companies don’t have the luxury of large sample sizes and a decent test might take weeks or months to gather sufficient data.
If the cost to run an A/B or other usability testing method is equal to or larger than the expected value of a successful test, then it’s certainly not worth it. Just do what the Hi.P.P.O says and call it a day.
2) Choose Your Battles Wisely
Also, remember that there is a personal cost to endlessly challenging everyone’s suggestions and testing every little thing: People might hate us and we might lose the will to fight.
While we should never senselessly bow to authority, sometimes it’s worth it to just add that stupid link to the CEO’s pet project in the footer.
Will it impact the site performance? Probably not.
Will it make the CEO happy? Yes.
Would insisting on testing it just irritate the hell out of the CEO, the engineer who has to implement the A/B test, and the data analyst who has to do the custom SQL query to crunch the data? Yes.
Is all the aggravation and declining team morale going to make it harder to get buy in for running the next test? You betcha.
It takes courage to stand up, challenge authority, and insist on what is right.
But courage, willpower, and team morale are finite resources. Don’t waste them on stupid stuff.
3) Authority Ends Debate
There is a third cost (sensing the theme?) to running tests. The cost of debate.
The ‘product’ of lean startup is knowledge, so any company activity that doesn’t produce knowledge is wasteful.
Debating does not produce knowledge. It is a wasteful activity.
Analyzing results is not debating. That’s a useful activity. But debating opinions? Pure waste.
This is where the Z.E.B.R.A comes in.
Fear the Z.E.B.R.A
Where the Hi.P.P.O takes charge via authoritarian structure, the Z.E.B.R.A has the most fearsome weapon of all, pure arrogance.
Z.E.B.R.A = Zero Evidence But Really Arrogant.
(Credit for this brilliant acronym goes to Emily Chiu.)
The Zebra is often someone with “expertise” who “really knows the customer” but doesn’t have any facts to back them up. Sometimes this is the PM or the CEO, but more often it’s the UX person. (Sorry UX folks!)
Based on years of design experience, we just know that the button should be red, the image should be smaller, and the shading on the button should be 4 px, and, god forbid, not 3 px.
This is far more dangerous than the Hi.P.P.O because while the Hi.P.P.O can be swayed by facts, the Z.E.B.R.A. says, “The customer is wrong.”
The Hi.P.P.O is a default decision. In the absence of facts, do what the boss says.
The Z.E.B.R.A rules through the tyranny of expertise.
For all the Hi.P.P.Os out there: Try to live by this mantra, “I’ve made a decision. If you’d like to change the decision, bring me facts. Define an experiment that will prove me wrong, and I’ll back it, but the debate is over.”
For the Z.E.B.R.As: Repeat after me, “All opinions are equal in the absence of data.”
We think it always helps to know what ‘good’ looks like. So we’re sharing this to help you work out how you’re doing compared to industry best practice.
The 3 columns represent the different levels of an Ad-hoc, Managed or Leading product management function.
The 5 rows represent the 5 areas we believe are critical for success. On the infographic each area has a checklist of questions to understand more about how you’re doing.
You can use the model to review the maturity of product management in your company.
Our experience is that the level of maturity required will depend on the size and complexity of your business. And most businesses find that their level of maturity varies across the 5 different areas.
Also performance within a company will vary over time and across the business. We often find some pockets of excellence and yet other areas that are woefully deficient.
However we do find this model is a useful tool as it moves the discussion on from talking about symptoms i.e. late deliveries or poor product revenues, to looking at what the root causes might be.
7 things you need to know about UX if you’re a Product Manager (by Dan Healy @danrhealy)
The worlds of product management and user experience (UX) are closer than they’ve ever been – especially for software-based products. If you want to deliver a product that your customers will love then you need to know about UX. But do you, as a Product Manager, really know about UX? Here are my 7 UX tips for Product Managers.
1. You are not the user
If you only take one of these tips away with you, take this one.
I’m still shocked by how many Product Managers I hear making decisions on their users’ behalf without having spoken to any. ‘Users will hate that!’, ‘Users will love that!’ – that sort of thing. If you want to know what your users will love or hate, ask them – stop guessing! Better than that – test an idea or prototype with them. Oh, and, start calling them customers not users.
2. Understand what UX is and what it isn’t
UX isn’t just about making products look good. It’s about making products work beautifully because they meet the exact needs of the people that need to use them.
To achieve this, you’ll need the distinct-but-complementary skills of a User Experience (UX) Designer and a User Interface (UI) Designer.
The UX Designer’s job is all about finding out what customers need through research and then using this insight to create and test early designs (wireframes) with representative customers. These can then be developed into interactive prototypes that can be further tested and iterated upon.
It’s typically at this prototyping stage that a UI Designer can add the most value. They can help to transform the experience into something delightful through visual design, colour, typography, layout, and branding. To get the best results, UX and UI Designers should work in close collaboration.
3. Don’t do it yourself
UX and Product Management are close but that doesn’t mean that the skills needed to perform each role are interchangeable. Don’t get me wrong, this doesn’t mean that Product Managers can’t create wireframes and UXers can’t have product ideas – it means that these things shouldn’t be done in isolation.
One of the most-challenging Product Managers I’ve worked with started our relationship by telling me that he would do all the customer research and it was my job to create wireframes that matched his expectations. This, of course, wouldn’t do. Instead, I convinced him to go out on the road together, meeting customers and carrying out guerrilla usability testing as we went. This led to one of the best working relationships I’ve ever had with a Product Manager and allowed us to deliver one of the best products in our industry.
4. Usable doesn’t mean valuable
As tempting as it is to allow a group of very smart people to lock themselves in a room to dream up the next new product for your organisation, you need to make sure that you validate the idea with representative customers as soon as possible. If not, you could end up delivering something that you love but your customers just don’t get.
I remember working on a product for a company some years ago. My job as UX lead was to deliver the most frictionless e-commerce journey possible.
When it came to usability testing, the journeys tested well. When we asked customers whether they’d buy the product they said no. Why? It was because we, as a company, weren’t the sort of company that they would expect to buy the product from. It was a powerful lesson in learning that usable doesn’t mean valuable.
5. Your UXer is your friend
As a UXer, it’s very easy to feel unloved (sniff). After all, you’re the person that makes trouble, slows things down, and wants to change everything at the last minute, right? It doesn’t have to be this way.
If you involve them early enough, your friendly UXer can help you to deliver the kinds of delightful products that your customers will love so much that they’ll carry you through the streets on their shoulders. Well, maybe that’s going a bit far but you get the idea.
It’s also worth knowing that you can innovate through user-centred design. One of the best projects I ever worked on involved stripping a bloated Frankenstein’s monster of a product right back until there was almost nothing left. Customer research had told us what customers needed from the product. This, coupled with lots of iterative usability testing allowed us to deliver the biggest sale in the 17-year history of the company and a bunch of industry accolades, including a UX award. One industry pundit put it best when he said, ‘no-one is doing anything like what you are doing’. That felt pretty darn good.
6. There’s always time for usability testing
It’s a common myth that there’s no time for usability testing. There’s always time for testing – even if a product has gone live.
It’s better to have a backlog full of items that you know will help you continuously improve the product than a list of features that you think will delight your customers. Oh, and, you don’t have to have a usability lab.
7. Everyone’s a designer
A few years ago, I joined a company as its first ever User Experience Designer. I’d been hired to work out why its flagship product has stopped selling.
On my first day, one of the developers introduced himself and shook my hand. ‘I’m so glad you’re here’ he said, ‘we’ve never had anyone design our software before’.
This was a great way to start my first day but it simply wasn’t true. Every time someone had written a word of copy, chosen a colour, decided on where something should go within the product, they were making unconscious design decisions. All of these will have an impact on how easy to use your product is.
Recognising that everyone who has input into your product is a designer is an important step to becoming a Product Manager who takes user-centred design seriously.
It also means that you can test ideas in their rawest form. Anything that can communicate the conceptual idea of your product is a design and worth testing – even if it wasn’t created by someone with the word Designer in their job title.
There we have it. As someone with lots of experience of working with products and Product Managers from a UXer’s point of view, taking these on board will make you a more customer-focused Product Manager and help you to deliver products that your customers will love.
Dan Healy (@danrhealy) is an award-winning Senior User Experience Designer and public speaker working at the cybersecurity company, Sophos. He’s been taming complex products for nearly 20 years.
Are you working in a business where single customer deals are driving priorities in development? Does it sometimes feel like it doesn’t matter what’s desirable for the product and the wider market, the business assigns higher importance to the next customer deal?
We see this happening in start-ups where the next deal results in a ‘pivot’ that sets the business in a new direction (as does the next deal and the next…). But it also happens in mature businesses where the next deal is a big chunk of money, perhaps millions, and it’s oh so tempting to take the money and change development priorities to make sure that the custom solution demanded gets delivered.
Whilst we all want a ‘can do’ culture in which we’re responsive and agile, going down the custom route provides short-term gain whilst storing up pain for the future.
Each custom deal, taken in isolation, might make sense. It means a new contract has been signed which brings in some money and makes people feel good, it keeps a customer happy and maybe even gives you a new reference for future deals.
But it’s too easy to ignore the downsides…
The development of ‘product’ needed for multiple customers (maybe existing customers) gets delayed while the best people are pulled onto building and delivering custom solutions (usually to tight timescales).
A culture of ‘customer-first’ means Sales don’t have to learn what’s possible or best for the business but feel free to sell whatever their customer wants – selling ‘futures’ or ‘the customer wish list’ rather than ‘what’s on the truck’.
Deployment and support must deal with yet another variant which is time consuming, messy and expensive, potentially leading to multiple code streams and a fragmented operating model.
Profitability on these bespoke deals either doesn’t get measured or is measured incorrectly because costs are not allocated properly across commercial deals.
And, product launches start to take years rather than months with costs spiralling out of control.
Over the long-term these downsides can cripple the company’s ability to profitably serve its markets. For that reason, many companies we work with are making the transition ‘from projects to products’.
It’s a well-trodden path but there are many challenges along the way and the purpose of this blog is to share some lessons learned.
There are 5 key things to get right:
• The culture must change: The culture that allows Sales (or Senior Management) to sell whatever the customer requests needs to go. A key tactic to support this is to highlight and communicate the impact that comes from shifting current plans to accommodate custom projects so stakeholders recognise the ‘pain’ to the business from pursuing custom requirements. This cultural shift needs to be led by the most Senior Management. There has to be a realisation that saying Yes to something means saying No to something else.
• Measure behaviour: The shift from selling projects to selling products needs to be measured and rewarded. Targets should be set (usually be Senior Management) for moving from projects to products. For example, if you currently do 80% projects and 20% product then set a target to change the balance to, for example, 60% project and 40% product next year (or 20% project and 80% product if you think that’s feasible). It needs to be made harder for the front end of the business to persuade the business to create a custom project than it is for them to sell what’s already available. Review the real costs and profitability of those large complex deals … they may be high revenue, but what about margin and the impact on the wider business?
• Improve your sales training and support: Whoever is doing the selling needs to know the portfolio, to be able to position and sell the value of what’s available. That takes training and it takes sales skills – some of the sales team might not have the skills they need.
The product managers’ role is to instil enthusiasm in Sales to sell the product and then equip them to so. Yet, in some companies, product information is woefully inadequate with poor descriptions of what’s available, lack of competitive insight, no clear understanding of what customers really value, a lack of clarity on target customers and on the key messages that will get them interested.
• Put product people in the driving seat: A common factor we see in project oriented businesses is that product managers are bypassed. We often see Sales people going directly to Development to get an estimate for effort and delivery timescales. Development are keen to help (as they want to build stuff that’s valued by customers). Senior Management then get told about this great opportunity and that Development are supportive. A margin gets added and the customer gets an offer for the custom work. Product managers might or might not get told what’s happened but even if they are, it’s often too late to influence the decision.
• Get ahead with your market understanding: You should be doing proactive research to try and understand where the market is heading in advance of these customer requirements coming in. This allows you to create the governance where you can say ‘no’ to things that are only relevant to a few customers and focus on things that are valued by the wider market where the opportunity is much bigger.
Product Management can have the reputation of being the ‘sales prevention department’. The implication being that we don’t care about commercial success. Of course, that should not be true – we should care passionately about the commercial success of our products. But we have a longer term view than sales teams and that means that we should say ‘no’ to individual deals that would delay us from product enhancements aimed at meeting the needs of the broader market.
This might be contentious but sometimes there needs to be a formal block on Development having one-to-one discussions with Sales. A better model is for a sales person with a custom request to engage with technical pre-sales (if that team exists) who may be able to steer the customer back to a standard offering. If that doesn’t work then they talk to the product manager. The product manager can say if what’s been requested is on the roadmap, can decide if a roadmap item can be pulled forward and can propose alternate solutions. And, they can also say ‘no’ – if what that customer want isn’t as important as what’s on the roadmap. There are tools that can help with this process – see our blog on Roadmap Prioritisation.
Transitioning from a project to product orientation isn’t without pain but it will lead to better long-term outcomes:
Faster, more reliable deliveries of product
Better alignment and efficiency across the business by selling what’s available and delivering what’s been sold
Taking control of the product strategy rather than being led by the customers who shout first or loudest
Better profits through fully embracing the ‘build once, sell many times’ philosophy
Are you in the process of making this transition? Have you just started?
If you need some help then please get in touch at firstname.lastname@example.org
I was recently catching up over coffee with a product manager who attended one of our product management training courses a couple of years ago.
He told me about the success they are having with a roadmapping prioritisation process that he learned about on our course.
Ian Threadgold is Head of Product Management at a growing SaaS company called Kallidus. They provide software products for enterprise customers to support their Learning and Development (L&D) and Human Resources (HR) functions.
“Last year one of my big headaches was trying to get agreement on what we put on our roadmaps. Everyone had a view. Some had very strong opinions. Trying to get agreement across all the different stakeholders was a nightmare.”
“It was really tough because priorities kept changing day by day. It depended on the latest sales deal, a major support issue or something we had promised on a previous roadmap. So the roadmap was constantly changing which lost us credibility with customers and made it impossible for Development.”
So Ian introduced a version of our roadmap prioritisation process into the business.
Each key department, Sales, Support, Product Management and Marketing, gets a say in scoring new ‘candidate’ ideas that are put forward for the roadmap. The scoring is from 0 to 5, with 5 being the highest. They can all put forward any ideas they have at any time.
Sales might come back from the latest customer discussion with a candidate feature that they believe will clinch a deal. They propose it and so might score it with a 5. Then each of the other departments need to score it as well. Using the pre-agreed weightings Ian can work out a final score.
“We use these scores as part of our quarterly planning cycle. We pick off the candidates with the highest scores from the top of the backlog and lock them into the next quarterly roadmap. Once this is agreed it can’t be changed and Development know they can get on with them. We use 2-week sprints so that’s 6 sprints per quarter. We like to think of each quarter as a giant sprint.”
Ian went on to say …
“Now we have a process that involves all the key stakeholders. It’s transparent, so instead of us just saying we think it’s a good idea, everyone can see the logic that’s used to come to a decision. It’s made our lives so much easier. And interestingly we’ve ended up doing the stuff we expected to do anyway.”
But it’s not always straightforward. Sometimes stakeholders try to change the weightings to get something that they think is really important onto the roadmap.
“To begin with we had a bigger weighting for new sales because that’s what was really important for the business. But now as customer retention is becoming more important we’ve increased the Support weighting to 30%. The Marketing score was added as they need cool stuff to be able to talk about in the market.”
When I asked Ian why he was so pleased with the process he said…
“It feels like we’ve got to a nice compromise between the Waterfall and Agile way of working. Things are clearer, we get less hassle as everyone from the CEO down has bought into the process and we’ve regained control of the roadmap.”
More info on roadmaps …
There are various ways of doing this prioritisation process. The one we teach on our training course also includes some scoring for the cost to the business. Please read our Product Management Journal on Roadmaps to learn more about the process and other aspects of roadmapping best practice – including our 5 steps to creating a perfect Roadmap.
If you want to find out more about Roadmap best practice or any area of product management why not check out our training courses.
Product Manager Personas – to help understand what you should be doing.
You may already use personas when developing propositions or working on requirements, but have you ever thought about using product manager personas?
They’re useful because they help product managers think through the skills they need, and the behaviour they should exhibit, to be successful.
And that behaviour will change based on where the product is in its lifecycle and the role of product management in your business.
The different personas are explained below.
The Product advocate – champions and promotes their product within and outside the business
The Troubleshooter – moves across the business sorting out product problems, resolving customer issues and fixing broken processes
The Expert compromiser – takes a view on what’s best for the product balancing the commercial, technical, operational and strategic issues
The Subject matter expert – knows their product inside out (or knows where to find the answers)
The Creator – comes up with new ideas and innovations for the product
The Owner of the numbers – knows exactly what’s going on with the Key Performance Indicators (KPIs) for their product so they can spot trending problems
The Reliable project manager – drives things forward and gets things delivered
The Voice of the market – understands what the market wants and acts as focal point for customer requirements within the business
The Mini CEO – runs their product as if it was their own company, conducting things like an orchestra all around them
If you’re working on a brand new product then Voice of the market, Creator and Product advocate are important roles. If you’re working on a mature in-life product, Troubleshooter, Expert compromiser and Reliable project manager can be important.
The 9 product manager personas
So which personas are you?
If you asked your boss, which personas would they say you are?
And if you asked them what do they want you to be – given the products you’re managing and what’s going on in the company – would it be the same?
We’ve come up with 9 personas but it would be nice to have a round 10. Can you suggest one that might be missing?
The business strategy book, Playing to Win, has several approaches that can help product managers be successful. Our focus in this blog is on one of these – the need to establish a ‘winning aspiration’.
So, let’s get started – what is a winning aspiration? Let’s look at each word in turn.
What does it mean to ‘win’?
It’s quite simple – are you beating the competition?
To work out if you’re winning, you need to talk about the performance of your product in your market space. Targets for revenue, profit or customer numbers might be important, but they’re not sufficient. To know that you’re winning, you need to measure your performance compared to that of your competition. That means metrics such as market share, superior financial returns, higher customer satisfaction, or something similar. These can be difficult to find out.
Of course, the reality is that most products fail to deliver against their commercial targets. And the book contends that unless you aspire to win, and put in the appropriate effort, the best you’ll ever achieve is mediocrity. You need to aim high.
But, this is not how most product managers behave. For many, getting the product delivered is their target and they dislike setting in-life performance targets against which they may be held accountable. It feels scary. After all, if you don’t tell people what you’re aiming for then you can’t be accused of missing the target!
And, it’s not how companies typically behave.
Many invest significantly in launching a lot of products (spreading their bets), but then under invest in making the products successful once launched. If, as a product manager, you ask for significant and sustained investment in your product it will probably come at the expense of investment elsewhere. Depending on how much confidence your company has in your product and marketing insight, this will either be considered positively – as a ‘laser-like focus’ on key products or will be considered negatively ‘putting all our eggs in one basket’.
That’s why you hear of General Electric’s requirement for its business divisions. They must by the leader or second in their market. That’s because the leader has the biggest share of profit in a market. And they’re prepared to invest heavily to succeed. If that doesn’t work, they exit the market and focus elsewhere.
And what is meant by an aspiration?
The aspiration is a statement about the future state you want your product to achieve. You might consider this the ‘vision’ for the product – it is an attractive, inspiring guiding statement of what we’re aiming to achieve.
Having a winning aspiration is valuable because it helps keep everyone focused on what’s important. It will help you develop your product canvasses, business cases, roadmap, product plans and strategy. It will help when there’s a need to prioritise and decide how to deal with day-to-day demands for resources and change. And, it helps you stop doing sub-optimal things so you have the resources to focus on the activities that are most likely to deliver a high level of success.
When it comes to defining your winning aspiration, it should focus on the customer and what they care about. So, for a mobile operator, the aspiration would not be to have the biggest mobile network, but it might be to let customers connect from more places and more easily than any other network. In this example, the winning aspiration would help network investment decisions – investment in partnerships for WiFi network and adding low cost 3G network infrastructure to plug coverage gaps might align better with the winning aspiration than rolling out an ultra-high speed network.
Without a winning aspiration, it becomes more likely that you’ll simply react to competitor activity rather than taking proactive decisions.
Whilst winning aspirations might be tweaked from time to time, they ought not to change often. They’re being used to influence product investments and the allocation of internal resources. Flip-flopping from one winning aspiration to another will stop you getting people onside and pulling in a consistent direction.
These are the do’s and don’ts for setting your winning aspiration copied from Playing to Win.
Do play to win rather than simply compete. Define winning in your context. Paint a picture of a brilliant successful future for your product.
Do craft aspirations that will be meaningful and powerful to your team and to your customers.
Do start with customers rather than products when thinking about what it means to win.
Do set winning aspirations for your products. Ask who are your customers and what does it mean to win with them.
Do think about winning relative to your traditional and best competitors.
Don’t stop there. Develop the rest of your strategy in support of your winning aspiration.
Do you have Coconut and Iceberg products in your business?
We’re all living longer. According to a UN report, the number of people over 80 will more than triple by 2050.
One of the paradoxes in product management is that there seems to be many more products launched than are ever withdrawn. So, are products living longer too? In the product management lifecycle do they never get to the end-of-life stage?
In the fast-moving world of technology, we don’t believe that’s true – products are being brought to market and replaced faster than ever. Even so, many older products are left to slowly sink into oblivion. We call these Iceberg or Coconut products.
Coconut products don’t bring in much money, but it’s obvious that the cost to run them is not high, so it’s not worth the effort of picking them up and dealing with them. Some profitable revenue is coming in for little or no effort. The sun is shining, albeit not very brightly, in the world of coconut products.
Iceberg products are different. The outlook is colder. Like coconut products they bring in little revenue and have few customers. But, what’s hidden from view is the enormous cost of running them. No one really knows if they’re profitable or not. Also, no one wants to spend the time and effort to find out. It’s easier to assume that someone else must have already checked the profitability. The conclusion is ‘leave well alone’ until something forces you to deal with them.
Unfortunately, that’s not necessarily the best approach.
Iceberg and Coconut products
A couple of years ago I was involved on the periphery of a merger between two big companies each with a large overlapping portfolio of products. The team I was in did some work to analyse the profitability of all the products in each company. We found about 400 in each, but also worked out that 80% of the revenue came from about 10 products. The remaining 790 only brought in 20% of the revenue!
When we looked at the cost to the business of running these 790 products it was huge. Very few were profitable and we identified the following issues.
• Ownership (i.e. who the product manager was) was often unclear.
• For some, the sales materials were so out of date that no one was selling the product even though it was apparently part of the portfolio.
• Contractual agreements with customers were not always easy to find, so obligations and the implications for the support of customers and the products were unclear.
• For others, when there was an issue, the support team could only provide very high-level answers. No one had any experience of the product as they had long ago moved on to newer things. Support issues quickly escalated through to product management and some unlucky product manager spent days tracking down the answers from disparate people spread across the company.
• On other occasions, there was a sudden panic because some of the underlying technology that one of the products relied on was being changed. This required some development effort to keep the product running. This could hardly be justified based on the small number of customers using it. However, there had been no pre-warning to customers about withdrawing the product, so the development resource was shifted from working on something much more important to fixing the issue.
There had been some half-hearted attempts to close down some of these products. But they often failed because one of the customers using the product was really important and no one wanted to upset them and jeopardise the relationship.
Although both businesses in the merger were profitable, there had not been any detailed work to understand the individual profitability of products. The reporting, processes and focus were just not there. Many costs, such as support costs, were spread out across all products without a detailed understanding of the real cost per product.
Plus, there was little incentive for anyone to look at rationalisation of the portfolio. The glamorous work, the projects that got you noticed, were launching new products.
It wasn’t just the costs of running these products that were not tracked or recognised. The opportunity costs were also not considered. Having Development, Support and Product Management resources tied up on these products meant they couldn’t be working on new things.
No one recognised that there were so many iceberg products floating around nor their huge cost to the business. It eventually took many years, and a major programme, to drive the rationalisation and replacement of these products and services – at a huge cost.
Our view is that every product should have a product manager looking after it. And, every product manager should know whether their older products are coconuts or icebergs. That means having a clear idea on whether the product is profitable or not and how strategically important it is.
Many companies tackle this with an annual review of the whole product portfolio. This allows them to do some long-term planning about migrating customers from old products to new ones, withdrawing products, understanding strategic fit and tracking individual product profitability.
Don’t let iceberg products sink your business and may the sun always shine on your coconuts.
You may have heard the expression ‘where the rubber hits the road’? It’s the point at which a theory or idea is put to a practical test.
It often seems that the people working on creating new products get all the glory compared to those of us working on in-life products.
New product development is exciting. It’s a world of possibility. Working on ideas that will potentially bring big rewards to the business. It’s all about the potential upside with little talk of failure – which makes it easier to get people enthused and on-board.
It’s also a chance to learn new stuff, get in front of senior management with good news stories and develop your career.
In-life, on the other hand is where reality bites. Of course, things can go well, but often they don’t. Let’s be honest, most products fail to hit their commercial targets. The job is about dealing with day-to-day problems, fire-fighting and trouble shooting. Perhaps the product is under performing or internal sales teams are focused elsewhere. So, you have to battle within the business to get things fixed.
In-life product management can feel like doing roadworks – a necessary evil. The job is tough and unglamorous. You often have to work hard with little recognition, get your hands dirty and persuade unwilling people to do what’s best for the product. But if you don’t, everything grinds to a halt.
Who, in their right mind, would swap working on new products for working on in-life products?
Well we would.
In-life products bring in the money – your role can have a huge impact. And working in the trenches helps you develop a strong feeling about all the moving parts needed to deliver success. It’s a great education in the realities of established business and not just start-up daydreams.
In many jobs, you will be working on new product development and in-life product management at the same time. Don’t neglect the in-life part – it’s where the rubber meets the road.
Dark Patterns are described as tricks used on websites and apps that make you buy or sign up for things that you don’t mean to.
The purpose of the website is to spread awareness and to shame companies that use them. And, it also wants to help you and I to spot these tricks so we’re not taken in by them.
When you use the web, you don’t read every word on every page – you skim-read and make assumptions. If a company wants to trick you into doing something, they can try to take advantage of this by making a page look like it’s saying one thing when in fact it’s saying another.
Let me show you an example that’s shown on the website.
I’ve removed the logo to protect the guilty/clever marketers – depending on your point of view.
I’m sure the A/B test went well on this… but is it good or bad design? And is it right or wrong?