Feature Buses & Release Trains

At one time, my product OpManager had several developers working simulataneously on a ton of features. Effort estimates were typically in the range of 6 – 12 weeks and features were started at different times. We wanted aggressive release schedules and synchronizing the release date to include everyone’s feature was close to impossible.

I came up with an idea – I told the team every month there will be a bus leaving (every month there will be a release) Whoever is ready can board the bus (Completed features will be included in the release) The bus will not wait for anyone.Whoever is not ready will get on the next bus.(The next release scheduled one month later)

Once we decided this, each developer was able to focus on building their feature without any undue pressure from a release deadline.

We experimented this process 2 years ago and it proved to be quite effective. What was surprising for me is that last week I read that a popular ecommerce company had a concept called Release train – very similar to what we were following, except that they called it a train instead of a bus ! Each month there was a release train and product managers decide who gets a ticket on the train.

Handling Pre-Sales

Handling pre-sales customers in a technical sale has some unique challenges. Here are some tips

A Prospect needs reassurance – not just answers – When a prospect faces a problem with the product, there are two things going in her mind.

1. What is the solution to the current problem?
2. Is this product proven and stable or is it full of bugs? (Will I get fired for suggesting this new product?)
When a Sales Engineer works with this prospect, usually they focus on the first question. They work with the prospect and help them resolve the issue. However if they do not address the second question (which is not asked) a lot of times, the sale does not happen. A successful sales engineer provides a comfort to the prospect where they not only solve the current problem, but also provides the reassurance or comfort that the prospect needs that this is a one-off issue and that the product is really stable and that help is available a phone call away.

Relate to customers problems
I have seen Sales Engineers demo products, where they just talk about the features of a product. “This is the home page etc. etc. and rattle on their product demos from start to finish without asking me who I was and what I wanted. The most impressive demos however always started with questions to understand what I need and then presented the products capabilites and clearly showing how it could solve my needs today, if I had the solution implemented.

Identifying Add-On candidates

Creating a shrink wrap product means identifying the Lowest common denominator in terms of features that can be included in the product to make it attractive for several customers. When you have a large-enough customer base, Add-on opportunities open up.

 

A simple technique to identify good add-on opportunities would be to look for features that would be valuable only to a subset of customers. For example, if you are building a Asset Tracking software, support for tracking MAC assets can be made as an add-on. An add-on opportunity should be niche-enough, so that a good section of your users don'e need it and large enough to provide an attractive revenue opportunity. Another example would be the Exchange Server monitor which we built as an add-on for our Server monitoring software OpManager.

Moving beyond your first product

Product Line Management
Many successful companies find it difficult to move beyond their first product, as they get caught into building new features and supporting the existing product that they never get the resources to start something new. Successful Product Managers constantly focus on, plan for and execute growth opportunities. Here are a few ideas -

Expand your addressable market – See everything else that you could be doing. If you are selling photocopiers, can you also sell paper and supplies? Can you also offer photo-copiers for rent? Can you run managed photo-copying service for your customers? Can you service photo-copiers ?

Find new customers for your existing products – With minor modifications can you open up newer market segments for your product? Can you tweak your IT Helpdesk to become a Customer Support software? Can you also add a few features and make it a HelpDesk for Schools? Or Hospitals ? Or lawyers ?

Build New products to sell to your exisiting customers – If you are already selling Email software to Enterprise IT, can you sell Anti-Spam solutions? How about Anti-virus ? Patch Management ? If successful products can be compared to  racehorses, then it definitely makes sense to breed many horses and not depend on only one.

Creating magic with small teams – Ownership & Pride

In small product teams usually the Product Manager also has to don the role of a Project Manager. As a project manager of a Product team here are a few things you should never forget
1. Shipping on time – In a Product company, you are not working for one customer. So it is more important to ship a quality product than to ship a product on time. Even if you ship on time, if the product quality sucks, nobody is going to touch it.

2. The importance of relationships – Your team is more important than deadlines. The relationship that you develop with team members and the relationship among team members themselves is very critical for the long term. It is important for you to realize that you have to make several short-term trade-offs in order to create a world-class product with your team. What you are attempting is a marathon, not a 100 m dash.

3. Throw away your Project Plan. Maintain a simple To Do list instead. If your small team is working aggressively on a prioritized list of features, there is nothing much you can do than wait for them to complete it. Don't get in their way and pain them under the context of status reporting meetings. Abolish status meetings. In small teams it is very easy to identify who is working hard and who is not. So you don't need to track project status and % completion.

4. Ownership & Pride – Allow people to come up with their own plans. Sell them the big picture benefits and include them during the initial requirement planning stages. If people do not own their modules (or features) then there is no pride in implementing it. If you determine all the tasks that need to be done and hand-out work orders to your team, you can rest assured that your product is doomed for failure, no matter how smart you are. Ownership creates passion. Passionate employees create outstanding products. This passion can never be substituted by one person's brilliance.

5. Learn to let go – New managers often fall into this trap of trying to control team members. Recipe for disaster in Product Management – Hire a leader who micro-manages, tries to control every hour of team member's time and always plans everything himself and tells people what they are supposed to work on each week.

6. By Default Trust (everyone). If one person misuses the trust, you can deal with it easily in a small team. Do not penalize 95% of your people, because 5% misuse their freedom.

7. Read the book "First break all the rules". It shatters conventional people management theories and is a must read for anyone who manages people

Usability Check List – > What is the Next step? (Navigational issues)

Usually we have different developers working on different features. But that does’nt mean that the customer has to go to ten different places and configure things to get one simple task working. A good solution would be to provide links to the customer for the logical next steps.
For example – in a procurement system, after adding information about a vendor, a logical next step can be to add products supplied by the vendor.
In a network monitoring software, after creating an alert profile, the logical next step could be to associate this  profile to several devices.
In screens where manual data entry is required (For eg, New Customer ) usually providing options to “Save” and “Save and Add New” would enhance usability. The key here is to think what does the user want to achieve here? Why is he on this screen? And then lead them to the logical next step.

Usability Check List -> Users should not think

While  designing forms check if each field in the form is absolutely neccessary. If you can avoid asking the user for input, avoid it or atleast put in a default value. Identify each place where the user is forced to think in a screen. If too much of thinking is needed then your UI is not intuitive. Check these simple things first

1. Trigger words – > Are you using simple, intuitive words which trigger the right input from the user? Example – “Email Alert” is simpler and more effective than “SMTP Notification”
2. Use Standard Terminology -> It is always better to go with common terms that the user is already familiar with (Thanks to Windows and Microsoft) than introduce new and unfamiliar terminology. Example – “Save as” is more familiar to users than “Save and ReName”.
3. Consistency -> Throughout the product be consistent in usage of terms, icons and their placement. It is not okay to have different icons for “Save” in different screens of the same product. Common mistakes would include  pop-up windows where one version as “OK” and “Cancel”, another that has “OK” and “Close” and a third version which says “Save” and “Exit” all with different behavior. This kind of inconsistency makes it difficult for users to get used to the product.
4. Prior Knowledge – Do you expect users to know (or learn) stuff to understand your product screens. Bad usability. For example in our network monitoring software – OpManager product 50% of users do not know what SNMP(Simple Network Monitoring Protocol) is ? What is the point in asking them what the SNMP Read community string, write community string and port numbers are ?
If you can avoid asking these, provide a help card below the screen explaining these to users and definitely provide default values. (If they do not know about it, most probably they would’nt have changed it !)

Building Solutions for a Market (vs. Building solutions for a single customer)

A lot of Product Managers fall into this trap. A lot of times, especially in the initial stages of the Product, a special customer comes by and promises to buy 200 copies of your software or pay you 100K if you would just add those few missing features in the product without which the product is useless to him. And then you start building these features. And the customer who promised to buy 200 copies, just buys a single copy and says the approval from his top management did’nt happen. Worse, if you accept a PO for 100K and start doing custom development for this large customer, you risk putting your whole product plan in a big risk.

It makes a lot of sense, to simply understand the difference between building a product for thousands of customers and doing custom application development for one customer. Learn to say NO to custom development, no matter how lucrative the deal appears to be. In some cases, certain customers would like you to develop a product itself and they are willing to fund the development. Even here accepting a PO upfront and entering into a project agreement would be a mistake as it is almost impossible to predict an exact release date for a product. Better would be to engage the customer early on, promise them early access milestones and accept feedback, but accept money only when you are ready to sell and support a stable version.

Include Cool Features in 1.0

At the time of planning the first release, you may run into certain features which may be very exciting but are not really critical for the core functionality of the product. But it would be a mistake to avoid these features as non-critical or designate them as low priority requirements. A lot of times, these exciting features can actually cause your products to succeed. These features can give your product a unique identity.
Example: The iPod wheel in my opinion is a truly remarkable feature. However it is not very critical for the core functionality of an MP3 player. (An MP3 player has to be able to play a song, skip a song, browse playlists etc. right) There were probably hundreds of MP3 players before the iPod. This remarkable wheel today would be the single reason why the iPod is so COOL compared to other products. (In fact it is what gives an identity to the iPod)

Feature Prioritization after the first release – Counter = N rule

After your first release there will still be a lot of feature requests also from existing users. I use a simple technique for identifying market-specific features which I call Counter = N rule. When you prepare a list of features that have been requested by customers, include an imaginary counter with each feature. During the initial stages of the product, I will not build any customer-requested feature till it has been requested by atleast 5 customers. Each time a customer requests a feature we will increment this imaginary counter by 1. So when it reaches 5 we know that this is not a customer-specific feature, but a market-specific one.

As your product becomes more and more popular, it makes sense to raise the counter threshold (N) from 5 to 10 or 20 or 30, so that your development team always works on the most prioritized list.

Prioritizing features – The 4 bucket methodology

Prioritizing features can be a quite daunting task for Product managers in the initial stages of a product. There is so much to do with scarce development resources. Especially when you have a huge list starting from building a web client, to customizing the user interface, to supporting Change Password, exporting reports to PDF formats etc. How will you ensure that you ship a good 1.0? One question that any new Product Manager will face is “Is there a scientific way of prioritizing features for a release?” Even though I’m sure there is no scientific way, I have seen different product managers use different techniques. Also if the Product Manager happens to be a techie, then cracking a big technology challenge naturally becomes a 1.0 priority. If you have someone in your team who is obsessed with Usability (That’s good by the way!) then that shows right from release 1.0. In this section I would like to outline a simple methodology that I use regularly for feature prioritization. I call it the 4 bucket methodology.

It is a simple way of grouping features as

Domain Features

Infrastructure Features

Usability / Navigational Features

Bugs (This is the 4^th bucket which usually comes after the 1.0 release)

 

Domain Features – This includes all features that form the core business logic of the product. For example for a CRM system, this could include features like Lead Tracking, tracking tasks and events associated with a lead, assigning a lead owner, converting a lead into an opportunity and finally an account.
For a network Monitoring system this would include automatic discovery, supporting maps, periodically monitoring for availability of devices or raising alerts when a problem is detected.

 

Infrastructure Features – This would include features like building a web client or supporting automatic backup / restore of Database, building failover capability etc.

Usability / Navigational Features – This would include features like building a Search Component or having a navigational component to traverse say 50 – 100 items at a time or sorting items alphabetically. A lot of times users simply expect these features to be there. They don’t submit feature requests for these, but someone will definitely crib when they are pained when have to manually search through an unsorted list.

Bugs – This is self-explanatory. A list of bugs reported by customers in the current release.

For the 1.0 and early releases it is advisable to focus on rapidly adding domain features and doing the Usability or Navigational features that are absolutely necessary. We can pick one or two of the most important infrastructure features and execute them and postpone everything else. For example, if we are building only a web client, then obviously that has to be included. But Database backup / restore and failover capability can wait.

This is inline with our philosophy of Understanding the goal of 1.0.

For subsequent releases, once the domain features are covered to a major extent, it is important to dig deep and perfect infrastructure and usability features and keep adding minimal domain features. Note that now is the time that the product is being used in production by real users. They want every release to make their life better. Users will not appreciate new features, when their current problems still remain unsolved.