About Roadmap Integrity
Roadmap Integrity was founded with one simple goal: to help senior managers make their companies more effective at creating great software that delivers maximum business impact.
While that’s a simple goal, there are some subtleties:
- The content, tools, and services we offer are not just for technologists. There is plenty of great material on that already. Instead, we focus on the interaction between technology teams and the rest of the company, because that’s often where problems start. If you are a senior manager—technical or not—and your success is dependent on your company’s software team’s effectiveness at delivering business results, Roadmap Integrity may be for you.
- Roadmap Integrity is not just for “software companies” or “technology companies.” See Do You Create Software? below.
Common Challenges in Creating Great Software
If your company is effective at creating great software today, congratulations! You deserve it. However, in our experience, companies face many challenges:
- Projects that fail to deliver expected business results despite careful planning, detailed requirements, and seemingly good execution
- Missed delivery dates, especially when people make external promises and commitments your company can’t keep
- Startups that grow past the point where the founders can keep everything in their heads
- Unable to “innovate” or make the “big bets” that make a difference
- Dysfunction and tension between “business and IT” or “development and product“
- Frequent arguments about project priority
- Frequent “fire drills” where everyone drops everything and scrambles to deliver the latest “top priority” project
- Unable to pay down technical debt, overhaul/replace aging code, or solve severe stability / reliability / performance problems
- A significant number of “80% complete” features rushed out the door to make a date but never truly finished
- Senior management with angst about whether they are really getting the business bang for the software buck. Executives with a technology background can often deal with this, but for those who don’t (increasingly, most of them), technology teams are bewildering black boxes they find frustrating to manage or communicate with
Does any of this happen at your company? You’re not alone. In fact, every company creating software faces some of these challenges occasionally. The problem is when these occasional challenges turn into chronic conditions. They reduce morale, productivity, and—left too long—competitiveness and your ability to attract and retain top talent.
What Can Be Done To Address These Challenges?
Of course, there’s no silver bullet or magic wand to fix everything overnight. However, there are some relatively simple basic principles which can make things better—or to prevent bad things from happening in the first place. If you diligently apply these principles, we believe you will find your company becoming noticeably better at:
- Creating a collaborative environment for consistently delivering great software, on time
- Delighting current customers and attracting new ones by solving their most important problems and meeting their greatest unmet needs
- Ensuring your software investments have greater business impact
- Getting your technical teams more involved, engaged and integrated with the rest of your company
These basic principles are accompanied by a simple but effective process for joining forces across the company to create and maintain your company’s software roadmap. While roadmap may not be a familiar term, it’s a very simple idea—it’s a set of software projects / features / releases plotted against time, usually by quarter or calendar/fiscal year. It’s the operating plan for your company’s software team, telling everyone where they are going—hence the name. Note: if you do an Internet search for “product roadmaps” you’ll see plenty of examples, but that’s not exactly what we’re talking about. (See Pretty Roadmaps below.)
The takeaway? Roadmap Integrity is here to help you create your company’s software roadmap, making your company more effective at creating great software that delivers maximum business impact.
My name is Bill Bliss. I’ve spent the last 25 years creating software for a living: from MS-DOS and Windows® to the Internet, from consumer to enterprise, from email to search, from shrink-wrapped software to SaaS, from venture-backed startups to Microsoft. Over the years, I’ve had the privilege of working with literally thousands of talented developers, designers, QA folks, product managers, marketers, and salespeople. I’ve worked on spectacularly successful software and, I’m not afraid to admit, on some spectacular failures. I’ve worked with some amazing leaders and visionaries and some who were, frankly, not so much.
I’ve always been fascinated by all aspects of how and why software is created: the business and competitive goals motivating the investment, the underlying technology and architecture of the code, how people come together as a team to build it, and the pure magic by which useful and sometimes even revolutionary products emerge from the primordial ooze of creative people’s ideas. In other words, I really get into this stuff. I’m an unapologetic geek.
I developed the Roadmap Integrity Process for my own use and have used it successfully in the last few companies I’ve worked for. It works, and the teams who use it love it. I decided it was time others should benefit from it too, so I formed Roadmap Integrity in 2011 to take what I’ve learned over the years about managing software projects, including the Roadmap Integrity Process, and share it with more people. I will document the basics of the process on this website, and make most of it available for free. Of course, I hope that some of you may want some coaching to actually get it working, and that you’ll contact me to help you do so.
Before forming Roadmap Integrity, I was VP and GM of Search and Recommendations for Myspace, a division of Fox Entertainment and News Corporation, joining as part of the turnaround team in June of 2009. Our team launched a faster and much more capable internal search platform based on open-source search engine SOLR, a better and faster user experience, a new general-purpose platform for serving recommended content, and the metadata platform underneath Myspace Topic Pages and Facebook Mashup. (I won’t even try to explain what a “metadata platform” is. Very geeky.) While the Myspace turnaround effort was obviously unsuccessful, the Search and Recommendations team still managed to do some nice work. (To be clear, the Roadmap Integrity Process was never used for Myspace overall; we only used it on the Search and Recommendations team. And, yes, I tried. Several times.)
Prior to MySpace, I was VP of Emerging Technologies for the Boston-area SaaS company Gomez, Inc., which purchased the Seattle startup Klir Technologies where I served as CTO. Prior to Klir, I was a senior vice-president at Expedia, Inc., responsible for Expedia.com and Hotels.com product management, product roadmap, and business analytics. Prior to Expedia, I spent over 16 years at Microsoft in a variety of senior technology and management roles. As general manager of the Natural User Interface group, I worked on advanced search and user interface technology for Windows, building on my experience as general manager of MSN Search. We launched MSN Search in 1998; by 2002 it had grown to over 100 million queries per day, well over $100M in annual revenue, and 34 international markets in 13 languages. Prior to MSN Search, I was one of the founding members of the team that designed and built the first two versions of Microsoft Outlook: I have been granted nine U.S. patents related to my work on Outlook.
Origins of the Roadmap Integrity Process
Over the years, I always tried to pay close attention to what went well on software projects and what didn’t go so well. Similarly, I listened to and watched managers I admired, studying how they were able to concisely communicate a compelling vision and rally the troops to create great products; when I managed teams myself, I did my best to emulate these leaders. That’s where I learned how important it is to take the time to carefully articulate compelling goals and to maniacally focus on them: you get a kind of “organizational leverage” that, when you have it, is electrifying; when you don’t, makes it a drag to go to work in the morning.
But it wasn’t until 2005 or 2006 that I started to think seriously about why projects went well or not. I figured that if I could isolate the good things and do more of them, then identify the most common bad things and avoid them, we could raise the odds that a project would succeed. While it was usually fairly easy to isolate the root cause of failure, so to speak, it was different for almost every single project. Perversely, it was even harder for the projects that went well—is it what you did, is it what you didn’t do, or both? (It’s both, of course.) There seemed to be literally thousands of things you had to do right, and thousands of things you had to not do wrong, in order to have a successful outcome. For a while I tried to solve the problem with an extremely complex product requirements template, and Expedia experimented with implementing the project Stage-Gate® approach, but both of those were heavyweight and unwieldy processes. There had to be a better way, but I just didn’t know what it was.
In 2006 I purchased a book on Amazon called The Laws of Software Process: A New Model for the Production and Management of Software,* by Philip G. Armour. It rocked my world. (As I’ve mentioned elsewhere, I am a geek!) I won’t go into detail here, but suffice to say that the principles in that book explain a lot about why projects succeed or fail. The problem was, the book is a little hard to get through even if you’re familiar with software development processes; if you aren’t, it’s impenetrable. Here it was, the explanation for why millions of dollars or more goes to waste every year, and the people who needed to know wouldn’t understand it. I even emailed Mr. Armour and asked him if he ever did consulting to non-technical senior managers, but he never replied. Enlightened but disappointed, I filed it away in the back of my brain.
Fast forward to 2007: I was CTO of a small venture-backed startup called Klir Technologies. It was there that I realized that Armour’s “levels of uncertainty” applied to more than just writing code: it applied to product requirements and other areas, such as product support, legal, finance, SEC regulatory issues—anything you need it to—depending on the business and a company’s history with software projects. I realized that execution risk and Armour’s “levels of uncertainty” were essentially the same thing, and that the concept of risk management applied to software development as well as finance. Shortly thereafter, I figured out how to operationalize it as part of our monthly project planning process, and I’ve been refining it ever since.
* The link to Armour’s book contains an affiliate code. If you buy the book after clicking on this link, you’re basically buying me a latte. Well, you would be if Amazon sold lattes, but you get the idea. Thanks!
People who work at “software companies” already know that creating great software must be a core competency. But what about everyone else?
Before the Internet, creating software wasn’t something most companies needed to be concerned about, at least outside of their IT departments. That’s changed. Today, many CEOs, CMOs, and other senior executives without technology backgrounds find themselves personally involved with software projects impacting their businesses, whether they want to or not.
Should creating great software be a core competency of your company? One way to think about it is to ask the following questions:
- Do you dedicate significant resources to maintaining and enhancing your website? A website is just another kind of software.
- Do you employ people who create and maintain your website or other software for your company—developers, quality assurance staff, or product managers?
- Is custom software—software written by you or to your specifications—critical to your business success?
If you answered “yes” to one or more of these questions, then your company creates software, and presumably there’s at least one team or organization inside your company responsible for it.
If you do a search for “product roadmaps” (particularly image search) on Google or Bing, you’ll see a lot of pretty pictures, each of of them with a different way to visualize a set of product features/releases plotted against time.
Don’t be confused or intimidated. These types of roadmaps serve a special purpose, to communicate product strategy to a specific audience:
- By software and hardware companies to current and future customers and partners
- To senior management, boards of directors, or investors
- To employees in an “all-hands” or “town hall” type meeting
We call these Pretty Roadmaps because they need to be polished and simplified for the specific audience. They are almost never useful to the software teams themselves as an operating plan; they are too high level.
You may or may not want or need to communicate your software roadmap in this way to a specific audience. If you do, the Roadmap Integrity Process will generate most or all the “raw data” needed to produce a Pretty Roadmap.
But it’s important to realize that a Pretty Roadmap is not the primary goal of the Roadmap Integrity Process. The value comes from the process itself and in following the Roadmap Integrity Basics.