Blog
Roadmapping - How Your Product Finds Its Way
I think this is my most immediately useful post so far. It’s a technique that has helped me work with individual entrepreneurs, my own products, venture funded companies, and giant corporations.A startup will often live or die based on its first product release. Did it get released? Did people find it useful? Good roadmapping dramatically improves your chance of getting to “Yes!” on these critical questions.
A roadmap is just a list of the features that you want to build, sorted in priority order. It might be easy for one person to make a list like this. However, it gets a lot harder if you are trying to get an organization, even a small one, to agree on the roadmap. It gets even harder when the stakes are high – when you have only one chance to release a version 1.0 of your product, and you need to make the right decision about what goes in, and what doesn’t go in. You can’t risk bloat, delay, mistakes, cloak-and-dagger politics, or bloody civil war.
I have developed some roadmapping techniques to get through the process smoothly and make the right decisions. I have used this with individual entrepreneurs, my own products, venture funded startups with 50 people, and big companies with separate divisions for product development and marketing.
I believe in releasing early and often. This allows you to minimize risk, and to collect customer suggestions for rapidly improving the product. My goal is to find a small set of the most important features to go into the next release. If we have the discipline to do that, our chance of success is high. If it is a new product, I am looking for the minimum useful release, which will start a process of incremental improvement.
In order to be free to apply this much discipline, you need to be politically aware, and you need to make sure that everyone feels that his/her request will eventually be accommodated. If people believe they will get what they want eventually, they will let you cut down the next release to get the most gain in the shortest time.
I recommend three stages:
1) Brainstorming. The goal of this stage is to collect all of the outstanding requests, develop ideas, and make sure that no one feels left out. In this stage, we expand our list as much as possible.
2) Categorizing, Voting, and estimating. In this stage, you try to get some consensus on what you should do and can do. Put a time bound around this – for instance, one hour of discussion, or two days for emailed comments.
3) Sort by priority. You may need a benevolent dictator to make the final sort. Then, go down the list and draw a line under the minimum set of features that will make a useful next release. If this is a first release, you want to make it lean. Make sure that everything you have above the line really is needed for the product to be useful. If there are any complicated features on the top of the list, try to break them apart into steps. In this stage, you apply discipline to shrink the next release.
Voila! Your shining prize, your next release, is now at the top of the list.
If you are making software, you now have a roadmap that you can drop directly into the ticketing system for an agile development process, complete with milestones or “Iterations”.
You can create a more complete roadmap by drawing more lines, representing additional future releases. It’s a good idea to assign dates to the releases. Once you pick the dates or the release frequency, you should always release on time. This fixed-time, variable-feature strategy is an important part of agile methodologies. It reduces risk and makes it easier to gather feedback that improves the product. If you can’t complete everything that is scheduled, just move the bottom items to the following release.
Hints
* Break features down into smaller components. Often you can grab something simple out of what seems to be a more complex feature, include it in your first release, and move the less obvious stuff to a later release. That is a big time-to-market win.
* Consider specific “use cases”, or “scenarios” – really specific stories about how the product will be used, with the names and jobs of actual people you know. This will be most helpful in expanding the list of feaures.
* Define and prioritize themes, which are groups of related features. It’s easier to get consensus on themes than on individual features, and it helps everyone focus on the big picture. This is especially helpful if you are working on a mature product that already has a long list of customer requests.
* Use voting, and give everyone 10 votes. A voter can use all 10 votes on one feature, 1 vote on each of 10 features, or any other allocation of 10 votes.
ALWAYS schedule a follow-on release shortly after the upcoming release. It’s much easier to bump things out of the coming release and get it out on time, if you know the things that are getting bumped will be in another release soon after.
Note: This article was first published as at the On Startups blog because it had a much bigger readership that could benefit from this technique.
Two Kinds of Teams - Shared Leader and Single Leader
Should team task assignments be controlled by a project manager, or should each team member create and accept tasks? You can get a big increase in performance if you know when to use each of these methods of organization.
A client wrote: “my plan was to have them work separately first and then after they passed the one week test to have the ones we like work together. Is this not possible? I think we have a fundamental difference on the idea of a “team. Your model is a self-organizing group of people who work on the same code. My model is a group of people who work towards the same goal by writing individual components while making sure all the components interface correctly.”
I wrote back:
You might be interested in this: The Discipline of Teams.
A friend of mine, Doug Smith, wrote a series of books starting with “The Wisdom of Teams” and “The Discipline of Teams” in which he looked at how teams are managed. He believes that there are two different management structures.
1) One is the “team”, which is a group of people that self organizes in the sense that they pick their own tasks, and any one of them can lead the effort if needed. A team can form if people have a strong sense of a shared goal.
2) The other structure is the “single leader group”, in which a group leader figures out who should do what task at what time. That’s a classic management structure that can work even if the shared goal isn’t clear to everyone.
According to Doug, there are specific circumstances when you would choose a “single leader group” versus a “team”. I can see you making this type of decision at Grazr. Your work with Kurt is part of a team. Your work with the new guys is single-leader.
I liked these ideas, learned from them, and invited Doug to be on the board of directors at PowerSteering Software, where we hoped to implement tools for both methodologies. I’m a big supporter of the single-leader methodology when a leader is in place to make it work, and I use it myself when working with new guys.
How to Build a Custom ASP
In 1999, there was a huge surge in interest in ASP’s for enterprise software. By 2001, pundits declared the model a failure. One analysis was that ASP’s wouldn’t be able to effectively service enterprise customers, because the systems needed to be customized and integrated, and doing so would …
In 1999, there was a huge surge in interest in ASP’s for enterprise software. By 2001, pundits declared the model a failure. One analysis was that ASP’s wouldn’t be able to effectively service enterprise customers, because the systems needed to be customized and integrated, and doing so would destroy the favorable economics of the ASP. It’s now obvious that the ASP model wasn’t a failure. It just didn’t quite keep up with the extreme growth forecasts. Our ASP packaging at PowerSteering continued to be the leading version of the product, and companies like Salesforce.com delivered ever-better and more configurable products. ASP sales volume, market share, and sophistication continue to grow every year.
So what about customization and integration? Is that a shortcoming of the ASP model? Is there a way to combine the favorable features of an ASP - instant startup, always on, invisible upgrades – with the customization and integration that more sophisticated customers want?
A coincidence of timing last week highlighted the questions for me. I had lunch with David Skok of Matrix Ventures on Wednesday. Matrix claims to be the most successful venture firm ever when measured by consistency of returns and ratios of winners to losers. They make a rigorous analysis of business opportunities, in the selective style of an east-coast VC firm. Skok himself is a successful software company founder and CEO with more than one IPO under his belt. So, when Skok criticizes an approach, he probably has a very good point.
In this case, he took issue with my opinions on customizations. I was claiming that the facts on the ground for enterprise software customers are that they are supporting custom configurations. Instead of avoiding the issue, vendors should take the lead in delivering code, processes, and infrastructure to support these customizations and the related upgrade cycles. Skok argued that:
1) Vendors should be “market driven, not customer driven”. They should stick with a 12 month development roadmap and not get thrown off course by inevitable customer requests.
2) Customers don’t want customizations to the core product. They want a clearly defined and separated area of customization and configuration that goes against a defined API supported by the vendor. They know this will increase quality and reduce their integration and upgrade expenses.
3) It’s just too hard to support customizations and upgrades, so vendors are smart to avoid it.
In leaving, Skok said “I’m really interested in the ASP model.”
That’s where the coincidence of timing comes in. On Thursday, I went to New York to start an advisory engagement with a company called Foothhold Technologies. They make software – delivered as application service – which is essentially a Web-based ERP system for agencies that serve the homeless.
I was amazed when I learned two facts. First, that they have more than 50 ASP customers, and that a majority of them have some level of customization. Second, that they try to address every customer bug report and UI request in one day. They do a production release every day.
This company somehow swims against all of Skok’s objections.
1) They are totally customer driven. Virtually everything in the product was added incrementally in response to some customer request or planned customization.
2) Customers ask for changes in every aspect of this type of application
3) They have been doing this for years with a high level of reliability and one day turnaround.
Even more amazing, this level of service is delivered with a software and development architecture that was not explicitly designed to suport it. They have a four-person development team supporting a 500 screen, 200 table application with dozens of variations. Their application has grown up incrementally over eight years from a set of Progress 4GL scripts, that at one point became funneled through a Web gateway to create a homemade Web application server. All of the customizations are inserted directly into the same codebase, which is riddled with statements of the type “if Customer X then do Custom thing for customer X”. It’s a small team working with what has become haphazardly designed spaghetti code, currently being re-engineered.
Yet, it works. They are succeeding. They have more than 50 customers, have reached profitability, and are gaining market share. That’s a harbinger of the future, an existence proof for custom ASP’s.
“Blink” and the Art of Hiring the Best
What if you could tell, immediately, whether a given person is going to be a great addition to your team? You would be the greatest manager in the history of the world. Thats the promise held out by a careful reading of the book Blink, the Power of Thinking without Thinking, by Malcolm Gladwell.
Hiring the right people is the single most important thing you can do to ensure the success of an IT project. Good people do the right thing, do it fast, and do itwith minimal management intervention. This is especially true in software development, where the good engineers are anecdotally reported to be ten times as productive as the average contributor. I believe this, and I have invested time in recruiting to makes sure Im working with the best people I can find.
I have been working on my recruiting process for years, and some of my methods are rather unorthodox. For instance, I don’t interview developers until I am sure I want to work with them. I couldnt explain why this is important, until I read Blink.
The book shows that it is possible to make good decisions, based on a very small amount of information, as long as it is the RIGHT information.
Over the years I have tried a lot of different ways to qualify potential team members. I havedone interviews, puzzles, calls, chats, code reviews, trials, and reference checks. When I experimented with different methods of qualifying developers, and tracked the outcomes, I was surprised to find that most of these activities were useless. I want to ramp up my teams quickly, and many of these activities added a lot of delay to the process. Even simple Instant Messenger interview added about a week to the typical recruiting cycle. Some of these activities were worse than useless. For instance, if I did a phone or in-person interview, I often ended up liking a particular person, but hiring a bad developer.
Clearly, a lot of these qualification activities give you the wrong information.
Blink gives examples of how you can get the right information and screen out the wrong information literally. One example concerns recruiting players for a symphony orchestra. In the past, most orchestras would invite candidates for an interview, greet them, and then ask them to play an audition piece. But some orchestras now use screened auditions. In a screened audition, the candidate has a number, is not identified, and plays behind a screen. This gave opportunities to a whole new set of players, and resulted in better sounding symphony orchestras.
It turns out that personal interviews tended to result in the hiring affable, good looking men, and lock out some great players who didn’t fit a visual image of what an orchestra player should look like. Without the screen, the personal, visual impression of the candidate is so powerful that it actually affects the sound that the committee heard. They thought they were selecting the best audition player, but when they used the screen, and really were able to listen to the audition, they heard differently. The human mind, your mind and mine, is filled with powerful biases. Some of those biases are useful for making quick decisions, others are just misleading. Its important to manipulate your process to screen out the misleading stuff and get the good stuff.
Another example from Blink shows how you can speed up decisions by collecting less information. Emergency room doctors, when confronted with a person complaining of chest pain, need to decide whether that person is likely to be having a heart attack. They tested two diagnostic methods. In one method, they take three specific measures of heart function and use a statistical algorithm to calculate the likelihood of a heart attack. The other method allowed them take any set of measurements, along with interviews about key risk factors such as weight, age, exercise, and previous heart attacks. In this test, the statistical method with fewer inputs was more accurate. All of the other information, while intuitively relevant, was actually just confusing. And, collecting it caused delays.
So what is the right information? If you are hiring a developer, the best information is a direct test of their ability to work on software. I hire developers for distributed development teams, so it is relatively easy to put them into a trial. I just send some passwords, some documentation, and a trial task. I learn an enormous amount in just a few days by taking their (email) questions and seeing the results of their work. What surprises me is how efficient the trial is and how irrelevant everything else is. I save a lot of time and some money by giving all my qualified candidates a paid trial, even though I am paying for their time before I have screened them.
The best test of a candidate is their performance in the job environment you are hiring them for. The other stuff is distraction. I am trying to figure out ways to apply this trial concept to more job categories.
This type of trial is something that open source projects have been doing for many years. An open source project often has very strict rules about the developers who get commit privileges. If you have commit privileges, you are part of the core team that can modify the code directly, without screening by a project leader. To earn commit privileges, you need to participate in the development project and submit a series of modifications that pass review. So, our inspired by open source development process can give us the answer to a critical business question how to hire the best, quickly. The book Blink explains why its effective.
This article also appeared in IT Managers Journal
Reuse, Reuse, Reuse
A friend of mine used to say “that’s repetitive AND redundant”.
Three reasons why reuse is really important:
1) Customer awareness: Our enterprise prospects see reuse (in various forms, components, products, services) as a high-priority organizational mission, above open source. It was interesting that IBM saw reuse at the component level (not the app level) as the biggest contributor to the productivity of their community development initiative.
2) Statistics: I have been eagerly reading a book called Software Assessments, Benchmarks, and Best Practices, by Capers Jones. It has amazing statistics showing that of all the practices that contribute to a difference in productivity between a great project and a bad one, reuse of software and other artifacts is the most important by a huge margin, contributing a 350% difference.
3) Scalability. Reuse is important at the level of a development team, an organization (for instance, the Massachusetts state government), and an industry (50 states) – even the global open source community.