Category Archives: Product Management

Hard learned lessons from 10 years of creating and marketing new products

Minimum Viable Replacement: A new approach to replacing old systems

“We need to retire the old system by X date, so what’s the MVP we can deliver by that date to replace it?”

“What?” you ask, alarm bells going off in your head.

“You know, the 20% of the capabilities that meet 80% of the customers’ needs. We can always enhance the system later. We’re agile, and we can’t let better get in the way of good enough, plus there’s a bunch of stuff that’s only being used by a single customer, so they’ll just have to deal with it, plus the new Web version will be much easier to use.”

And so begins yet another digital destruction, er digital transformation, initiative. As someone who’s witnessed multiple multimillion dollar agile release trainwrecks, I’m going to introduce you to the concept of Minimum Viable Replacement, a new framework to help you replatform and retire systems. 

Minimum Viable Product vs Minimum Viable Replacement

In the world of agile everyone talks about minimum viable products, that smallest set of capabilities required to meet a segment of your customers’ needs. The concept popularized by Eric Reis in the book Lean Startup, is great for startups, and for companies entering entirely market or product segments.

Most companies are not startups, and instead spend most of their time enhancing and replacing existing systems to take advantage of new technologies and address competitive threats, not developing entirely new capabilities for entirely new markets, therefore MVP is absolutely the wrong approach for replacing legacy systems. 

If your company has been around for a decade or longer, then you need to be thinking in terms of Minimum Viable Replacement 90% of the time!

Think about it, your company has grown from a small company into a much larger company over decades, with multiple products serving customers of different sizes and business units across multiple geographies and markets, each with their own specific requirements. 

If you’re in the B2B space, your largest customers drive the majority of the revenue, and therefore get special features and customizations just for them, so rather than thinking about your largest customers as a segment, you really need to think of each of your ginormous customers as a key segment that will be very costly to walk away from.

And over those years, your software and other systems have been modified time and time again in order to meet the specific demands of your largest customers, fight off competitive threats, enter new markets, etc. Oh, and many of the people who made those changes have been synergized, retired, transferred, died, so no one even knows what all the systems do, and for whom they do it. 

On top of that you will encounter the Paper Clip problem, where creative users, have figured out how to get your system to work in all sorts of ways it was never designed for.

And finally, even as you’re trying to replace your old systems, customer, regulatory and competitive demands are still forcing you to enhance the existing systems, even as you are trying to replace them. 

As a result delivering a minimum viable replacement is typically exponentially more complex, costly and risky than launching an MVP, as you can destroy your company if not done right.

 An MVR = multiple MVPs

For the purposes of this article, a Minimum Viable Product is simply a validated hypothesis that a certain minimum level of functionality is enough to meet a specific market segment need. 

The key to a successful MVP is to solve a specific segment’s challenges first, instead of trying to solve multiple needs across multiple markets. 

A minimum viable replacement is usually the exact opposite. Instead of having to solve the needs of a very specific customer segment, you need to solve the needs for every customer segment.

An MVR is the sum total of all the MVPs required to transition existing customers and retire existing systems. So not only do you have to potentially replace all of the existing capabilities in order to keep your existing customers happy, you have to get your users to migrate to the new systems.

Especially in the B2B space, where software applications are generally integrated into larger processes and ecosystems, getting customers to migrate often takes much longer, and is much harder than even replacing the core capabilities. 

In addition, especially if you are in the B2B market, you cannot underestimate the importance of designing for the extreme use cases. Why? Because those edge use cases are often critical for your largest customers.

Remember, one percent of your customers will drive 90% of your complexity, so if you design and architect for the 80%, there is a good chance that your solution won’t scale to support your largest customers. 

A good way to envision this is to think about a 100-story condo. The “regular” folk live on the first 99 floors with 12 foot ceilings, fairly standard bathrooms, etc. and pay $10K in rent annually.  The 1% live on the 100th floor with their own swimming pool, heli pad, 40-foot ceilings, and all sorts of other crazy things, and pay $1M annually. If you design for the first 99 floors initially, and then get to the last floor, only to discover that 40-foot ceilings and a helipad are critical requirements, what’s the probability your design and architecture will support these “crazy” use cases.

Each of your largest customers, especially if you have done a lot of customizations, may need to be treated as its own segment with an associated MVP in order to successfully meet their needs. 

In fact, you may decide to have two entirely separate approaches. Standard architecture and design for the 99% and entirely custom solutions for the 1%, but that leverage shared services whenever possible.

Typically, most companies underestimate just how much complexity they’ve taken on to support their largest customers, and just how little concern the largest have for your desires to retire your systems, which leads to massively underestimating both the amount of work required to replace the legacy capabilities required, but also how many years it will take to get their largest customers to transition.

Unfortunately, the MVP approach almost guarantees that companies will fall into this trap, since it focuses on what’s the least we can do to declare victory based on a paradigm that has ABSOLUTELY nothing to do with retiring legacy systems

As long as you embrace the fact that it takes years to replace decades of development, not months or days, and that the road to retirement will be much longer than anyone anticipated, then you can plan for the unexpected, and take advantage of opportunities as you implement new components.  

After having been through multiple replatforming initiatives, i.e. from DOS to Windows, Windows to Web, Web to mobile, Mainframe to cloud, etc. here are just a few questions you’ll want to ask as you plot your replacement strategy are:;

  1. How much revenue comes from the top 1% of our customers?
  2. Do we understand the edge use cases, e.g. how the system is used to close the books at the end of the year, or when there is a regulatory audit?
  3. Who are our top customers, and what types of customizations have we done for them?
  4. How deeply integrated are our systems integrated into their systems? And how difficult will it be for them to adopt our new systems?
  5. What are all the downstream applications and organizations using our systems, inside and outside our company?
  6. How are these individuals and organizations using our systems and the data they produce?
  7. Can we segment our customer base by capability requirement? If so then can we Identify MVR requirements for each segment?
  8. Are there new underserved segments that don’t currently use our existing product because they can’t afford it, implementation complexity or because it’s not available on X platform, e.g. mobile, that would be happy that would be happy with a true MVP?
  9. Is the new product an extension of the old and should be initially sold as an add on or is it a true replacement? Sometimes you can start by offering an enhancement which can be sold as an add on and then later integrate core replacement functionality. 
  10. Is it better to piss off your existing user base or potential users? Oftentimes, we build functionality for a specific niche or customer and have to make hard choices about whether it’s worth supporting existing customers vs. serving a broader set of new customers. Just be prepared for the blowback as what makes sense on paper to you may not make sense to the VP of sales or service dealing with irate customers or trying to hit their quarterly targets.

Seven Deadly Sins of Enterprise Software Development & What to do About Them

Software is Eating the News: Are you in the in the Entertainment or Work business?

work-vs-entertainmentRight now, news organizations still haven’t really clarified what business they are in and/or what their audience is really looking for, as a result they often measure and focus on the wrong things.

Information technology businesses fall into two primary categories:

  1. Entertainment: The goal here is to help people have “fun,” to spend their downtime with you. And the more time spent with you the better. It doesn’t really matter whether that time spent makes them a better or worse human being, helps the planet, it’s fundamentally about entertaining people. Think Facebook, Pinterest, movies, gaming, etc.
  2. Work: The goal here is to help people take action and solve problems, whether pay their bills, stock their pantries, lose weight, learn new skills, influence public policies. In this case, the goal is to often spend the least time possible, as the primary thing you care about is the outcome. Traditional B2B software and Google search falls primarily into this category; you’re not using it for fun but to get the task done as efficiently and effectively as possible, and the less time spent the better.

So are journalists and news organizations primarily in the entertainment or work business?

Traditionally, they have straddled both worlds and as a result have muddied their value proposition, measure the wrong things and apply the wrong business models.

Additionally, what one segment of the audience and what journalists’ often think of as entertainment, others often think of as work, politics being one of them.

work-vs-entertainment-politics

In the entertainment world, your goal is to get people to spend as much time with you as possible, since the whole point of your existence is to fill people’s free time. In this scenario, display advertising as a revenue stream and products that encourage spending time make sense.

In the work world, your goal is to minimize the amount of time people spend with you and instead give them the answers to their problems, or eliminate their problems all together. In this case, the less time spent on your site/application is often better, since the goal is to increase their time. In this scenario, display advertising makes absolutely no sense and products that don’t solve problems are bad.

work-vs-entertainment-metrics

So should news organizations focus on delivering more entertainment value or more work value?

And that will be a question for another day. 🙂

Event Calendars: A Key to Community Engagement & Winning the Content Wars

Providing local residents an online event calendar is one of the most basic yet poorly executed components of community journalism.

So this morning, I went to the CommercialAppeal.com site on my tablet in search of events, and I couldn’t find it,  so finally I grabbed my laptop and after much searching found it buried in the entertainment section and then proceeded to get further frustrated with the search and overall usability. And then I went to see how I could submit an event, and the experience deteriorated even further as the site passed me off to a 3rd party to create the event.

I’m sorry but if news organizations can’t execute their local events calendar with any quality, then they have no right to survive – and honestly won’t and here’s why:

  1. Events are the ceremonies that help communities come together. Whether they be city council meetings, PTSA meetings, volunteer opportunities, community concerts, athletics events, TED Talks, you name it, community events are key to community life. And by not leveraging modern technology to help foster community, you are failing in your public-service mission.
  2. Event information validates, excites and engages your audiences. If you are hosting information about my event and helping me market it, then it gives me a reason to engage with your site and for me to market your site. And unlike Facebook, having your event “featured” on a news site provides validation as well, building a sense of connection to your organization.
  3. Content costs are nearly zero. Since the event organizer is entering the information, news organizations only need to screen for quality and not actually write up the events. This is the reason why Facebook is so profitable because they just provide the platform while others provide the content.
  4. Local events are a key to competing for a local audience. Today there is no single site or source for local event information, both pre and post event. Since so much of what news organizations are all about, this represents a perfect opportunity for news organizations to combine their brand equity, editorial skills and technology to differentiate themselves.

 

So what makes a great online event calendar?

  1. Comprehensive: Instead of forcing people to go to multiple places, allow them to go to one place for everything. It’s not just an entertainment calendar. It feature’s every local event for every type of local organization, neighborhood associations, school events, city council meetings, city planning meetings, sports events, meetups, chamber meetings, afterschool events, you name it.
  2. Intelligent: Users shouldn’t have to work very hard or at all to find the events and information they are looking for. Users need to be able to easily filter and find events that matter to them so the categorization options need to make sense to the users and offer a mix of open ended and fixed filters.
  3. Lazy: Help people be lazy and successful. Users should have information pushed to them on a regular basis and the option to have reminders embedded in their calendars so they don’t have to constantly search for options.
  4. Interactive: Ask users for feedback about the events they attended as a way to deepen the user engagement and transform the site into just a calendar into a conversation and drive engagement.

In order to succeed, news organizations will have to think of themselves first as  civic intelligence and engagement platforms that combine traditional journalism with design thinking and technology product management to develop new ways of informing and empowering their communities.

 

Naiveté Key to Starting any Project

At work I was recently asked, “Kevin, What’s was the secret to get your project funded?”

So I looked in the mirror, and quickly realized it wasn’t based on looks, and instead after much thought replied, “Naiveté, creativity, persistence & luck!” which frankly are the key ingredients for any successful project.

Why Naiveté?

In the beginning I thought it would take a few months to sell the project, and then someone told me it would most likely take six to 12 months, which both relieved me and frustrated me at the time. Ultimately it took more like 24-36 months before the project went from concept to funding

Honestly, I probably would have never tackled the project if I had known it would take two, almost three years before it was finally prioritized and funded. The reality is that you have to be naïve and overly optimistic about how long it will take otherwise you’d most likely give up before you start.

Why persistence?

Because while we all start out naively, success ultimately requires persistence, otherwise we’d give up before crossing the finish line, especially when the finish line seems to just keep moving further away. The challenge is to figure out the difference between persistence and stupidity, as success is never guaranteed.

Why creativity?

While persistence is critical, you need to keep coming up with different sales pitches and throwing them against the wall to see what sticks. And we came up with stories based on fear, greed, greatness, customer experience, you name it with all sorts of different charts that showing how we’d save money, save time, make money, grab new markets and so on and so forth as we drafted presentation after presentation. And each time our story became a little crisper, gained us new advocates and helped us slowly crawl up the prioritization list.

Just like any other types of sales, when you are asking for people to part with their money and resources, it’s rare that you create the perfect pitch the first time. Instead you need to view every pitch as an experiment, where you are making as many observations and potentially asking as many questions as you are answering, otherwise you are wasting time. So identify what went well and modify what didn’t – and keep selling until someone bites!

So what was the final ingredient required for funding?

Luck! Without luck, I don’t know that we ever would have gotten the required nor the desired funding, but part of luck is being ready at the right place and right time when the opportunity arises. And while most of us would love to credit our brilliance for success, and blame bad luck for our failures, the reality is that lady luck is equally present in both.

But without the naiveté to start, the persistence to keep going when it seems hopeless & the creativity to keep coming up with new pitches, you will rarely be in a position to enjoy lady luck’s sunshine.

So put on those rose-colored glasses, but with flexible titanium frames that will hold up to the abuse, and get started pitching!

Bad UX! Bad product management! Bad RIM! Or, why does my BlackBerry have a flashing light?

Want to know why the RIM management team should be fired and BlackBerry has gone from cool to crap?

The green flashing light!

Anyone who’s owned a BlackBerry knows what I’m talking about. In the top right corner there exists a mysterious flashing light – sometimes it’s green; sometimes it’s red. What it does and why it’s flashing no one knows and no one cares as far as I can tell.

Instead, it just irritates! At night if I want to use the alarm function or want to leave my phone next to my bed I have to cover it with a shirt or something else so it doesn’t bother me. I finally managed to figure out how to turn off the green light but now an orange one appears…. sigh 😦

I’m sure I can find out how to turn that one off as well but my point here is: How many tens of millions of dollars has RIM wasted on a feature that adds limited to no value – or even negative value over the years?

Just because a feature may have made sense in version 1.0 doesn’t mean it makes sense in version 2.0! As a product manager you have to be ruthless about what features to include and which you exclude.

Products are just like art – whether music, writing or photography – what you exclude is just as important as what you include. There’s a classic scene from the Movie Amadeus where the king tells Mozart, “It was good there are just too many notes. Just cut a few and it will be perfect!”

Take that too heart! It will save you money from developing drivel that few people use and frustrates even more users.  Even better, it will focus your efforts on polishing the key pieces your customers really care about.

Just imagine all the wasted engineering and design efforts that have gone into enabling the flashing lights. I can just imagine being in design reviews where they’re trying to increase their screen size but can’t because of the flashing light.

RIM wake up! Eliminate the flashing light and focus your efforts on what we really want: Touch screens, bigger screens and more apps! Until then I’ll wish I had an Android or iPhone.

Am I right? Let me know what you think.

Why I hate the term product manager

Product managers are supposed to be the voice of the customer and the market, but in most companies that’s a lie. Why? Because a product manager by definition is first and foremost responsible for their product – which is inherently internally focused. As a result, when they look at the outside world it’s almost always through the lens of their specific product.

Instead of looking at how their product fits into the customers’ ecosystem, processes, etc… they look at how their customers fit into their product – and then can’t figure out why adoption rates are so low.

And since in larger organizations each PM typically looks at the world through their product silo, it’s difficult to figure out how each of the pieces fits together.

So what can organizations do?

Create market, customer, persona or process advocates

Organizations need customer or persona advocates that aren’t tied to a specific product but instead responsible for becoming the subject matter expert on the markets, customers, personas or processes served by the company.

In some companies the UX department handles this but oftentimes the UX group is more focused on the screen design usability without understanding the larger context.

By making individual PMs responsible for being customer advocates it should help force the product managers to be more customer centric and drive collaboration across the organization.

Map the customers’ customers journey

I’ve read a lot about customer journey mapping but for the most part it’s always been in the context of the customer’s journey with your company. For B2B companies, mapping the customers’ customers journey may be even more helpful as it forces you to understand what your customers’ processes are and how you potentially fit or don’t fit into their processes as your number one goal is to help your customers be more successful.

By mapping the customers’ customer journey you should be able to spot opportunities to develop new products or better position your existing products to meet your customers’ goals.

Tell me what you think.