Roadmap Planning – The “King Solomon”

If you think of your roadmap as an “artifact” that just needs to be presented at 2 p.m. on Thursday, you’re missing an opportunity and also setting yourself up for failure.  Done correctly, the “roadmap,” is actually a process that you should be thinking and working toward every workday of the year.  Done right, your roadmap process is something you can manage to keep your team focused on your company’s “true north.”

The goal of today’s post is to highlight another sign that might signify that your roadmap process is working against your true aim.  This one is subtle and seductive. When first posed as an option it sounds completely logical.  In fact, you might even feel foolish arguing against it.  I call it the “King Solomon.”

The product planning process is full of emotion.  Anytime you’re reviewing the roadmap, everyone involved is on high-alert concerning his or her top needs.  In other words, all of your stakeholders have their defenses up and are burrowed in.  Good luck!  Once you’ve been through two or three roadmap sessions with your top team, almost invariably, someone brings up and advocates the King Solomon approach.  It goes like this…

The product direction oversight team does not spend near the amount of time prioritizing new development initiatives as you do.  In fact, except for their own pains and pet projects, they basically ignore it until your Thursday 2 p.m. roadmap meeting.  Executives’ mission in life is to solve problems, and it is in their nature to “solve” your roadmap issues inside the ninety minutes you devoted to a review.  This is bad news for your goal of keeping the company on its path toward true north.

Undertaking roadmap-planning sessions takes time and stirs up lots of difficult decisions.  The management team involved, many of which aren’t as close to the actual building of software, starts to better understand that they can’t have everything.  Making trade-off decisions is hard! Sooner or later it happens, the “King Solomon.”  You remember the story; two women come before King Solomon, both claiming to be the mother of an infant.  With no way to determine the true mother, King Solomon declares that the only fair way is to divide the infant with a sword and give each woman half.  His wisdom, of course, is that the true mother’s love will cause her to forsake ownership to save the life of her beloved child.  Unfortunately for your roadmap, what gets proposed is dissection, minus the wisdom.

Here’s how it works.  Because members of senior management do not confront the competition for engineering recourses daily, the way you do, when they get into your roadmap meeting, their instinct is to simplify.  It might happen in your first roadmap meeting, or it may be in your second or third, but here is how it goes.  In an effort to optimize resources, someone proposes the following.  “Hey, let’s do this.  Because we’re releasing software several times through the year, let’s dedicate a percentage of capacity toward each of several categories of development.”

The proposal is that for each release “X” percent of resources go towards sales features.  “Y” percent of features go towards customers satisfaction (a.k.a. bug fixes), and “Z” percent go towards “the platform.”  It sounds perfectly logical.  In fact, you may feel like an ass fighting such magnanimous, straightforward thinking.  Surely this is the right and “fair,” way to make progress on multiple fronts.  Management, in all its wisdom (within a ninety minute meeting anyway) basically guesses what percentage of resources each category deserves.

I typically shy away from military and sports analogies in business communications, but I can’t help it this time.  Confronted with three hills he needs to take, what military commander would divvy up his forces into thirds and attack all three at the same time?  I’m no warlord, but my guess is only a poor one.  In product planning as in a battle, you want to concentrate your forces on specific goals.  “Peanut buttering” your engineering efforts across all needs is the same as abdicating product decisions.

If you agree to the King Solomon, if you allow this to be enacted, you’ve just given up the role of product manager.  You have ceded the control you’ve earned through customer knowledge and expertise to a blunt force formula.  Don’t get me wrong, it’s not an ego thing, but if prioritizing resources were as easy as this there would be no role known as product management

Rightly or wrongly, if there is a “cardinal sin” in Product Management, it is idle engineers.  Rather than being focused on productive throughput, most of our industry is blindly focused on engineering utilization.  One of the best new conversations on the block is the entire Lean Startup movement, whose focus on product/market fit advocates doing and testing the right thing, not just doing.  In the meantime, don’t allow your true north to be hijacked by the King Solomon.

Your roadmap is not just an artifact.  It can’t be.  In needs to be a process.  Your goal is not to “close” the team on the proposals of a single two-hour meeting.  Your goal needs to be an iterative process built on trust, and improved over time based on delivered results.

Roadmap Planning – The (Algo)rithm Method

(Adapted from my ProductCamp Austin presentation- “The (Road)map Warrior- Tactics for a Product Manager’s defining battle“)

The most important role of Product Management is to keep a company or business unit focused on it’s “True North.”  As the product manager, you may or may not be the person who set the vision, but it’s your job to “carry the flame,” of what it means to be going after a market opportunity.  It’s your job to “grok” the customers you are aiming to serve, and to continually course-correct the organization to the path that builds out that vision. Unfortunately, one of the processes most associated with Product Management frequently hijacks a PM’s primary purpose- Road mapping.

The Road map process is a double-edged sword for Product Mangers.  If treated as a continual process, it can be a fantastic tool for helping your organization make investment decisions.  If treated as an event that happens once a quarter, it’s a mine-field of potential problems for both your company and your job.  Roadmap meetings seem to creep up and attack product managers at the least convenient times.  Fortunately, there are some signs that might signal you want to perk up and be more proactive about your process.  In this post and the next I’ll highlight two of those signs.

The first sign is what I call the “Algo”rithm Method.  I think that most every Product Manager has used this plan of attack at one point or another.  It goes something like this.  You’re a new product manager or a product manager at a new job.  Everything is new.  New company, new market, new customers, new technologies, new (to you) codebase.  As you do your rounds of meet-and-greets across the organization, you quickly figure out that the product you’ve inherited has lots of baggage (see Your Baby is Ugly).  You quickly start to feel overwhelmed.  But it’s okay.  You went to business school (maybe), you’re analytical, you can handle this. So what do you do? You build a spreadsheet!

Up to this point where there’s no harm there’s no foul.  If writing down and grouping customer requests, major defects, and interesting sounding feature definition helps you get your head around the product, go for it!  Where your “true north” becomes imperiled is in the next step, the “algorithm.”

Okay, maybe not a real algorithm, but what happens is that Product Managers grasp for a way to use data to justify what to build next.  Not the wrong instinct at all, but in this case there’s a “gotcha.”   First come the categories.  Revenue, customer satisfaction, technical debt, engineering effort, etc. The categories differ by the person building the sheet, but the idea is that you then score each proposed feature in some way.  These scores are then put into a “special magic calculation” (sorry, it’s PM black magic, we can’t disclose the code to outsiders), which then spits out a ranked priority of all requests.  The proverbial “Voila!” And of course this is where you’ve just shot yourself in the foot.

There are several problems with the algorithm method, but the most glaring is that you have just ceded all of your control as a product manager to a spreadsheet.  The seductive, slippery slope is that you now are of the mind that Microsoft Excel can “tell” you what order to build things in.  However, what no Excel formula (at least none I’ve ever seen) can really account for is, “your true north.”  This point will be lost in the ensuing meetings.  What happens instead is that the product manager pulls out the spreadsheet in roadmap meetings to help sell his or her proposed plan of attack.

First they go after the categories.  “What do you mean by Customer Sat? Does that mean you’ll fix all P2’s and P3’s?”  Several rat-hole discussions ensue.  You’re thinking ahead to when they’ll question the how the scores are calculated, but you’re never going to make it that far.  Right about here your founder/CEO typically pipes up, “Why is line number four an engineering difficulty of seven?  When it was just me building the product I could code that in my sleep!”  (And of course, he’s right, it should be a two, but you can’t very well tell him that it’s now a seven because we now have to build it to work inside the shitty spaghetti code he knocked out years ago in his dorm room!) The feeding frenzy begins.  Even if you’ve pre-sold the each “score” to its corresponding stakeholder, you haven’t sold it to all of them. You have already lost.

Again, if you’re just up in your Product Management tree fort banging this around to help get your head around things, fine. But just like it’s long-lost cousin the “Rhythm Method,” if you’re practicing the (Algo)rithm method and it’s working… it’s because you’re lucky!

(Stay tuned for another bad sign, as well as more discussion on staying on course with your true north).

Your Baby is Ugly! (Part 1)

Last summer, at ProductCamp Austin 11 I delivered a talk  titled, “Your Baby is Ugly (but I think we can fix it…) Strategies for the Inherited Product.”  Long winded yes, but they vote for what sessions actually take place, and to make it you have to get some wheat in behind the chaff!   My premise is that while most product people aspire to building the “new new” thing, the reality of first-time product jobs is more along the lines of stewardship of an “also ran” product.

Most product management jobs don’t start out with a clean whiteboard, a new market, and boundless opportunity.  The far more common situation for any first time product manager (or someone joining a new company) is that you will inherit someone else’s product.  And as luck would have it, as an unproven resource you’re going to be assigned one of the products with the least amount of revenue risk, an “ugly baby.”

What is an “ugly baby” product?  Well, the term comes from the jokes that accompany being a product manager in an organization still run by the founder who created the original product.  It’s the challenge as a subordinate that you can’t tell him or her that “his baby is ugly.”  It’s a Catch-22 situation for the product manager and the organization.  You are now charged with growing the product’s success and as such you talk to the market which is looking for improvements.  At the same time, the product got the company this far, and some of your proposed solutions prompt a “who are you to say it needs improvement,” type reaction.  That particular situation aside, I extended the “ugly baby” definition to include those products that are:

  • “Step-child’” Products – No offense to step children, but running the product step-child is not everyone’s favorite task.  Products in this category have been launched into the market, have enough installed base that company wants to “keep them alive,” but whose prospects for whatever reason have faded.  Resources in the company naturally “move away” from step child products.
  • Out-dated – Sometimes products are built on outdated technology.  Sometimes they suffer from being built on platforms that have the perception of being dead or outdated technology.  In the midst of the massive growth of remote access in the 90’s I couldn’t get the time of day for a product that extended our market to protect access to IBM’s AS/400 platform.  Client/server was the new, new thing, never mind how many mini-computers were still deployed and how easy the extension would be to launch.
  • Starved for resources – Almost by definition, as product manager of an ugly baby product you’re likely starved for resources.  The small amount of revenue and growth of your product dooms it to a smaller and smaller portion of the resource pie.
  • Overdue customer commitments – This may be less a type of ugly baby and more a frequent characteristic.  Since you do have an installed base of users for the product,  and since no software is ever “done,” there are still active (and often vocal) paying customers who at one point were promised “more goodies.” Unfortunately, the specific bell or whistle they were promised rarely overlaps with what your analysis shows the product needs to dig itself out of its hole.
  • Failed to launch – These products come in all shapes and sizes.  Senior management forced the product out too early and fizzled.  Product is fantastic but was too early in the market.  1.0 of the product was released to huge fanfare and then immediately considered “done” by management whose interests quickly pivoted to new things. Etc.
  • Forgotten in the Merger – This is one of my favorites, which I have seen again and again. Company A buys Company B for its strategic assets (e.g. a product line) that provide great synergy with company A’s product vision and strategy.  The resulting politics, jockeying, and merger-energy then all centers around combining these strategies.  Meanwhile, back at the ranch, company B’s second and third lines of business which were healthy and profitable pre-merger, begin to atrophy from neglect.

If you find yourself responsible for one of these types of ugly baby product there is good news and bad news.  The bad news is you’re going to have to fight, cajole, and just plain scrap for resources.  The good news is a combination of lowered expectations from your organization, and hidden opportunity.  “There’s gold in them thar’ products! (sometimes)”   In a Part 2 of “Your Baby’s Ugly,” I’ll describe the steps you can take to unearth that gold.

Have you Got Marketing? Three lessons from a High Tech legend

crusadersThe Crusaders were not nice people.” 

This is my favorite line from one of my favorite marketing books, Marketing High Technology, by William Davidow.  As he goes on to explain in the book, “Total marketing is a crusade.”  His point is that truly great marketing requires total commitment.

I’ve always been drawn to the concept because it’s an easy way to express the passion involved in driving a product into the hands the customers who need it.   When he says the crusaders weren’t nice people, he means they had a “killer instinct.”  I’ve jumped on a desk and yelled to rev up sales people, I’ve played a tambourine in front of 300 customers, and I’ve embarrassed competitors in public forums (by being 10x better – hey, they should have shown up!). Maybe the words “killer instinct” are over the top, but as a friend and coworker once described it to me, “I speak in burlesque.”   The competition of high-tech marketing is fun, and a little “over the top” is great way to capture that fun.

Bill Davidow ran marketing for the first computer division of Hewlett Packard.  As fun trivia, he was put in charge of that group its first general manager, Tom Perkins (who later founded Kleiner Perkins — I like High-tech history, and yes, the one in the news lately).  From there, Davidow went on to run marketing for a small company you may have heard of called Intel.  His book, Marketing High Technology, is now an old one, but it still stands up, and I continually return to my notes.  So I thought I’d share:

1-Without a channel, it’s not a product.”  –  It’s been my experience that to high tech product people, “place,” is the least sexy of the “four P’s.”  Unfortunately, it’s one of the most recurring and common mistakes in high tech.  It would seem that any company lucky enough to have a first hit eventually then hits this issue. The company is so successful selling product A that it decides it should acquire or build (or probably both) products B and C.  Massive investment is put into coding and or integration, and when it’s released it’s pushed on the sales force in a big push – “TADA! Now go sell it!”

“No hospital would order its staff of neurosurgeons to retrain for cardiac bypass surgery because it wanted to develop a new market yet the equivalent happens all the time to sales forces in business.”  

Davidow’s point isn’t that sales channels should not be changed.  Instead what matters is that when planning, senior managers fully understand that it takes a very large investment of money and time to effect that change.  The product isn’t “DONE” until the channel is built as well (and that may in fact be a bigger job than coding the software!)

 2– “A sales person’s most valuable resource is time” – Yes, blisteringly obvious, yet so blatantly abused and ignored by most high-tech marketing teams.  Sales is a difficult profession.  So much so that all other groups inside a high tech venture tend to hold it at arm’s length, even those who are tasked with helping them!

“One of the great maxims of business waste: There are never enough resources to do the job once at headquarters, but ten times as much energy can be wasted in the field and no one will bat an eyelash.” – Davidow

To the product management and marketing teams I’ve worked with I’m sure I’ve sounded like a broken record.  I repeatedly preach, “In a high tech company, everyones job is sales.” That doesn’t mean you need to pick up a bag and go on a call, but you should constantly be asking yourself what you’ve done lately to increase the time your sales people can spend in front of customers (or make that time more effective).

3- “The first step in selling a dog is to find a crusader!” –   Not every product is Facebook, the iPhone, or  Some actually need to be sold.

To be a “dog” product doesn’t mean the product is necessarily bad.  High tech markets are cruel.  We only need to go back to our Geoffry Moore to remember that over time all high tech markets settle into “First, Second, (sometimes) Third, and then…everything else.”  Frequently, sales of the “best” product, at least in terms of functionality that solves customer problems, can put them in the “dog” category. Starting late, bad marketing, and bad luck can all trip up good products.

All is not lost! (Maybe).  Sadly, not all organizations have the resources or the commitment to pull back and retrench, but it is possible to change position and to revive products.  As Davidow puts it:

“The first step in selling a dog is to find a crusader!  The second step is to reexamine the market. Try to find market segments where you can still win.  Narrow your focus.  Great marketing requires total commitment.  Total marketing is a crusade!”

Headspace, rise of the Micro-SaaS

WOW: In the 1994-95 time range, just when browsers and the Internet were beginning to seep into the world’s frame of reference, a co-worker and I used to always refer back to a single pane comic.  As people working at an networking company pre- and then post-browser, we thought it was wildly funny.  It was a single pane comic with two guys in an office.  The guy at the desk has a far off look (as best I recall) and in quotes at the bottom it has him saying, “I found the Internet, and it enriched my life.”  Anytime I find something on the Internet that makes an impression, either large and important or just whimsical, I think of that statement.

I’ve been using Headspace for about five months I put this decidedly into the “large and important” category.  And while the function and utility of a the app is interesting, I think the even more interesting concept is the success of the business model that comes along with it.

Headspace is a meditation app.  However, unlike the many 99 cent “white” noise maker apps out there, Headspace is a complete meditation solution.  Over the years I’ve made several “runs” at learning to meditate and weave regular meditations into my life.  Though the basic tenants of how to meditate can be learned in minutes, it’s something that is just difficult to do on your own.   The Headspace solution pairs content, in this case guided meditations, with a simple user interface that guides users through levels of exercises that build on each other.  In essence, it’s a meditation coach that’s always with you.  A complete solution for learning to meditate and then build a regular habit into your life.

Phew!  If you can believe it, that was the preamble for what I really wanted to talk about, the Headspace business model.  When I started off in the computer business, the early 90’s, software companies were called ISV’s (for Independent Software Vendor). In the early 2000’s, with the rise of all things web, there was a brief fad/storyline in the press about the rise of “Micro ISVs.” Essentially, web technologies were beginning to pull down the price of developing (and more importantly distributing) software.  This change lead to more and more small companies with only a handful of developers being able to produce and publish usable software.

The explosion of Apps that have come with smartphones and tablets has certainly come with an explosion of small software developers to create them.  We don’t call them micro-ISV’s so much anymore, but it’s the same basic model.  The problem with these models is how do you make any real money?  Don’t get me wrong, a single developer that sells million 99 cent apps through iTunes has almost $700k (pre tax) after paying the Apple toll.  Certainly a significant payday, but if sales of the app slow, what do you sell then?  Even the huge successes like Angry Birds have to come up with their next line extension or a new hit in order grow.

Games or big one hit wonders are fine, but what interests me most about Headspace is what might be called the rise of the “Micro-SaaS” company.  B2B Enterprise software companies are overwhelmingly moving away from large, installed, on-premise software sales. For them, the Software as a Service business model provides benefits both to customers and to themselves.  For a software vendor, the best thing about SaaS (there are so many to choose) has to be predictable recurring revenue.  Build a base of customers, put laser like focus on customer retention, and assuming your application is still relevant, you have a great way to grow and build your business.

Headspace is a good example of this small, recurring revenue type business. The app is free and features a set of “starter” meditations that let you try out the service – “10 for 10 – ten minutes a day for ten days” for instance.  At about $5.00 per month it doesn’t take too many subscribers to create a nice recurring income stream for the Headspace team.  They stopped publishing how many people are using it on their website, but last I saw I believe it was over 2,000, that’s 120k per year right there.

I have no insight into the business workings of Headspace, but from the outside my guess is that what they’ve done could certainly be done with a very small team– less than five people maybe?  The app itself is a very well done user interface, but we’re talking maybe 10-15 screens total. The hosting and streaming could be done through any of a number of providers (and is likely their largest actual cost).  Finally, most of the work looks to be in the form of content creation.  Each meditation is new and different, and hosted by the same person (ironically, most, maybe 80% of the content of 20 minute meditation is…silence!)

What interests me about this is the disruption inherent in this small format model.  I’ve made no effort to discover how many meditation coaches there are out there, but they’re there.  How many are going to lose business because one of them was smart enough to get online and be the one guy who has the potential to serve the entire English speaking world?  They lost me.  How many other professions or content creators will take this same path?  Why write a self-help book when you can “SaaS-ify” it and create a recurring stream.  Even if you charge twenty-five cents a month, there’s a break even where you’ll get all upside over the three bucks per book you’d get from your publisher.

Headspace is a “wow.”  I found the Internet, and it changed my life.

The “gamification” of walking

WOW:  Before today’s ever present marketing buzz word “Big Data,” but after the onslaught of “Social,” and “cloud” there was “gamification.”  Somewhere in the 2010 timeframe you couldn’t visit five company sites without two or three telling you how important it was to turn your enterprise application into a game.  Well, I’m not sure I buy it for your ERP system, but my new “use all the time” consumer product has me re-thinking my initial skepticism.   Fitbit is basically a suped-up pedometer, but the total package has turned every day movement into “keeping score.”

My first foray into the “Quantified Self” movement was somewhere around 2007 with a precursor to the Zeo sleep tracker.  It was a watch that you’d wear at night that would record the movement of your sleep.  The goal then would be to report to you how long you slept and how much time you sepnt in different types of sleep.  It was expensive and unwieldy to use. I was very happy when the (now defunct) Zeo headband came out.  Zeo worked great, tracking different types of sleep, synching to your smartphone and instantly updating nice charts that graphed your night’s sleep.  The hardest part of using Zeo was nothing more than having to remember to put it back in its charge cradle each morning.  Unfortunately, Zeo went out of business, and no one seems to have scooped up the assets yet. I’d be happy to reengage.

Over the past few years the price and size of components required to accomplish various wearable computing functions has come down.  This is great as a ton of new products have come on the market.  For about six weeks I’ve been using a Fitbit One, and I’m ready to call it a WOW product.

The Fitbit pops into a small water resistant sheath that you can clip to your pants or other piece of clothing.  The accelerators inside the Fitbit track all of our movement during the day and can give you a detailed  accounting of steps taken, flights of floors climbed, and even calories burned.  The single button lets you flip through these stats quickly at any time.  The combination of being able to see stats on the phone or viewing in real time on the Fitbit itself make it easy to track how close you are to your daily goal – the recommended ten thousand steps a day (of course I took a screen shot of the day we hiked Muir woods – believe me, not a normal day).

Where I think Fitbit gets better is the accompanying smartphone app (i use the iPhone version).  Opening up the app automatically kicks of a Bluetooth syncs with the Fitbit.  This takes about fifteen to twenty seconds to update.  Once finished all the current stats are viewable on the phone.  In addition, the app gives you a quick place to change settings on the Fitbit such as changing goals for a particular metric or setting the alarm.


The last bit of Fitbit functionality is strangely enough a sleep tracker that is pretty much modeled after my original 2007 watch.  This is probably the only part of the Fitbit experience that is not there for me yet. To use the Fitbit One to track your sleep you need to place it in the pocket of a small band that Velcros around your wrist.  This is comfortable enough.  The issue is that you have to put Fitbit into sleep “mode” (no modes!)  By holding down the button you tell it that you’re going to bed.  This is easy to do, but also easy to forget either when going to bed or when coming out of sleep in the morning.  Finally, the level of detail is a pittance compared to the detailed breakdown you had with Zeo.