This weekend I had the opportunity to mentor some of the teams at The Startup Center during the in50hrs event. The idea of the event was to conceptualize and build a minimum viable product within one weekend.

As a mentor, my role was to sit with teams and make sure that their product idea really was the “minimum viable product“. When you conceptualize a product, chances are you’ve got all these fancy use cases in your head. You’re thinking “Oh wouldn’t it be cool if we had this features” and “That feature would really be neat”. Before you know it, you’ve got a complicated product with many useless features.

Lets look at an example of how we can pare back the features into a minimum viable product.

Elevator Pitch

How often have you searched long and hard to find customer support numbers for companies? The numbers on many companies websites dont work (if you can find them) and Google is of no help. The idea is to build a site, with working customer support numbers for various companies. Users can add numbers they find and vote on other numbers whether it worked for them or not.

Initial Feature List

The initial feature list had a whole bunch of features for this product

• Search the database to find a company
• Allow users to submit companies to the database
• Group companies into categories
• Detect duplication of companies (eg: IBM vs International Business Machines)
• Separate numbers by city
• Get the user’s IP, determine the location and show numbers for the city closest to the user
• Upvote on numbers which work
• Downvote on numbers which aren’t working
• Allow businesses to add verified numbers
• Allow users to submit numbers to the database
• Have premium users who receive discounts from companies
• Premium users can login through facebook, twitter and google accounts
• Show users their vote if they have previously voted on a number

Wow, that’s a lot of features for the first release.

The Minimum Viable Product

Now how many of these are really central to the core problem being solved? My job was to cut away the extra features.

So we went through the list and thought about each feature in turn. Do we really need to categorise companies? Do we really need premium users? Do we even need authentication at all? Can everything be done by anonymous users?

Finally, we whittled it down to just these features

• Search the database to find a company
• Allow users to submit companies to the database
• Allow users to submit numbers to the database
• Upvote on numbers which work
• Downvote on numbers which aren’t working

That’s all you need for the MVP.

Think about your next product. Do you really need all those features for the first release?

In a previous post I introduced the Story Tree functionality of Silver Stories. Here is a video that shows how you can go about creating such story trees.

We had three goals when developing the interaction interface for story trees:

• Support different feature hierarchies: The video shows how we can use the Story Tree functionality to build a user story map, but you can create any other feature hierarchy too. You use a Theme->Epic->MMF structure? Or Goal->Feature->Story? You can model those too.
• Keep it visual: We are big believers in visual management, especially in the 10 foot, 3 second rule. We could have shown trees using the regular collapsible tree structure, but you lose all the context as you drill down or roll up the tree. By visually depicting the entire tree at once, you can always view your operations in the context of the entire story tree.
• Make it fluid: If the story tree is to support collaboration, the interaction had to be fluid. You should be able to create cards and move them around as if you were on a card wall. You can get remote stakeholders on skype conference call, share your desktop, and collaboratively build up the tree in real time as the conversations are happening. You can see that fluidity in action in the video above as we build up a small story tree in only three minutes.

So what do you think of the story tree functionality? We would love to hear your comments below.

We recently announced Silver Stories, a tool for agile portfolio management. In this post, I explain some of the problems that we hope to solve with Silver Stories. Click here for the entire series of posts on Silver Stories.

About User Story Mapping

User Story Mapping is a technique popularized by Jeff Patton that allows teams to build up a set of user stories by looking at the software from a user centric point of view. You could say that Story Maps are a combination of user centric design and feature breakdown trees. User Story Mapping is a powerful way to gain an understanding of scope for new product development.

The feature breakdown in user story maps is User Activity -> User Task -> User Story

User Activities are things that users do towards achieving a particular goal. For example, “Create a profile” might be one activity in a social networking website.

User Tasks are specific steps within an activity. Tasks by themselves do not move towards a goal, but are required components of an activity. For example, “Add contact information”, “Add education experience”, “Add hobbies and interests” might all be user tasks under the “Create a profile” activity.

User Stories are small end-to-end vertical slices of functionality that implement User Tasks. For instance, the “Add contact information” task could be broken into stories to “Add contact information”, “Edit contact information”, “Validate email address”, “Create a % complete progress bar” and so on.

Story mapping is a fluid, collaborative effort. Multiple stakeholders can participate on different sections of the map until a single shared understanding of the system is created. Cards are dynamically moved around, changing the order of the activities, grouping cards together under an activity or breaking cards down into tasks and stories.

Once created, the story map provides a good high level picture of the software to be built, along with a flow of activities from the user’s perspective.

User Story Mapping with Silver Stories

Silver Stories has a unique story tree view that allows stakeholders to easily create story maps. Here is a story map created using Silver Stories:

The story tree is visualized using a 2-dimension mapping of cards. This visualization enables you to see the entire tree at all levels of hierarchy on the screen at one time, eliminating the need to drill down through the hierarchy. The problem with drill downs is that you are always looking at sub sections of the system, losing the context in which it is placed. This visualization allows you to see user activities, user tasks and user stories within context.

Cards in yellow represent User Activities, cards in red are User Tasks and cards in blue are User Stories.

The shape of the story map gives an indication about which sections of the software contain the highest density of functionality.

Thus, the visualization of user story maps in Silver Catalyst use patterns, shapes and colors to convey much more information than can be obtained using a tabular form or a tree drill down.

Resources

This post only touches on user story mapping from a visualization point of view. For more on how you can use story mapping to collaborate with multiple stakeholders and create a shared understanding of the product, check out Jeff Pattons resource page on User Story mapping.

Kevin Mullet was in Chennai yesterday and he gave a talk on User Experience Design. Thanks to Serendio for organising the talk. I’ve attached below a mindmap of the talk based on my notes. Click the image to see the whole mindmap.

One of the cool things about Silver Catalyst (which is a Django app) is that you can start using it right out of the box. I didn’t want the team working their way around Apache and MSSQL configurations, Python version incompatibilities, database access issues and deployment hassles. The final solution was a simple executable, which when run would start everything required to get going.

In this post, I’ll explain how that was achieved.

A bit of background first. The vision for Silver Catalyst was a tool that could be installed by a team without having to get centralised servers and system administrators involved. I wanted the team to be able to set aside one computer on which they could install Silver Catalyst by themselves for use on their project. That made it pretty important that the setup be absolutely painless.

Silver Catalyst was written in Python using the Django framework. My first thought was to package the application as a zip of compiled python files and then have the team deploy that onto a server. This meant that someone would have to setup a web server, get Django working with it, setup a database, install python, deploy the application and finally configure it to point to the right files. Phew!

Luckily, to the rescue came cx_freeze. cx_freeze is a really nifty utility that will take your python code, check the included libraries and package everything along with the current python version into an executable. Very cool! A bonus was that you would not even need python installed to run the tool since the interpreter is packaged in the executable. This also eliminated issues like python version incompatibilities and so on.

Step two was the decision to use sqlite3 as the database. Since sqlite3 is an embedded database, you don’t need to have a database installed at all. Even better, there are standard modules to access sqlite3. In fact, it has been made a part of the standard distribution from Python 2.5 on.

The only dependency remaining was the web server. If I could use a pure python web server, I could simply hook up Django to it via WSGI and include the whole lot in the executable. That is what I did. I used ToofPy with some modifications so that it is pre-configured to run Django.

When cx_freeze is run on this setup, it bundles together the web server, Django, sqlite3, the application code, and the python interpreter into an executable. The application is pre-configured to use the packaged sqlite3 database code and the web server is pre-configured to load Django.

The result?

Just run the executable and the server starts. Access the server via a browser and you go straight into the Silver Catalyst application. In fact, because there are no external dependencies, it is easy to think that it is a native application. But behind the scenes, it is all python and some cx_freeze magic. If you want to see for yourself what the final result was like, you can download a free version of the tool here.

One of the dangers of developing an application is assuming that all your users are just like you.

Case in point: The Silver Catalyst tool that I am currently developing.

Imagine for a second that your team is using Silver Catalyst. They have entered all the data into the tool and are using it regularly. At the end of the week, an executive asks for the status. Because Silver Catalyst is a web app, the PM figures that the executive can just login to the tool anytime they want the status, and therefore creates a login for him. A couple of days pass and the executive asks for the report again.

Guess what? The executive never logged into the system! The PM is now back to taking data from the tool and preparing a report.

Sounds familiar?

There are a number of reasons why the executive wanted a report

• He is not used to using a web app. Old habits die hard. He is used to a report, so a report it shall be.
• He wants to email it to someone else.
• He wants to read it on the road, when disconnected from the network.
• He wants to print it out and give it to someone

There are many reasons why someone would need an offline version of the current status.

Interacting with your application online is just one mode of interaction. A lot of interaction happens outside the space of the application: email, paper, conversations, discussions.

An application that forces all interaction to happen through it will either be used reluctantly or will not be used by those who have different patterns of usage. Quite often, these people are key stakeholders.

When I first designed Silver Catalyst, I ignored this point. I thought everyone would just log into the tool and find out the status. Why do we need to provide PDF output? One of the outcomes of the beta test was that there were people looking for PDF reports so that they could email it around.

When I thought about it, it seemed to click. Most teams have a bug tracking tool that anyone can log into and see. Yet, how often have you been asked for a bug status report when the person could have just logged into the tool and found out? In my case it was because the regular pattern of communication is to go to the PM to find status, rather than going into a tool. Similarly we had a wiki that showed the status of various modules. Guess what? Key people didn’t read the wiki. They would email the PM instead.

So, does your application support alternate modes of interaction?

Theming, the ability to change the look of your product doesn’t matter. Right? Wrong!

In one sense, the ability to change the look of your software, the colours and the graphics and the fonts, is the most frivolous of features. It adds zero functionality to the product. Worse, most users are not designers and end up creating terrible themes. Why allow the users to mess it up when you could get your team of ultra-talented desingers to create a look that works for everyone?

Because software is used by humans, not machines, and humans have a craving for personalisation. Personalisation allows the user to feel like the software is theirs.

A lot of people have figured this out for consumer software. I can theme my GUI, change my shell, even mod my PC. And dont even get me started on mobile phones. Did you know that people actually pay money to change the way their phone rings? Of course you did. A few billion dollars worth of money. Just to change the way it sounds when a call comes in. Then add in all the other non-tech stuff that people like to personalise, like cars, homes, and even their own bodies.

So people love to personalise. It could be something as simple as ringtones or as complex as the case mods. The product looks the way we want it to look, it reflects our identity. Personalisation at any level allows us to feel a connection to the product we use. Ultimately, a positive connection between user and product is what keep the user feeling happy about using the product. Any feature that creates this positive response is a feature worth having, and personalisation is one of those.

All that is great for consumer software, I hear you say. What about business software? Traditional thinking is that business software should be functional, not aesthetic. When we think about business, the words that come to mind are “boring”, “uniform”, “standard”. As a result, business software is usually just that. Boring, uniform and standard. But you know what? Business software is also used by… humans! Admittedly to do boring business tasks, but that’s no reason for business software to be faceless. Why can’t the software wear the company colours? Why can’t the software look different for evey team? Why is it so damn difficult to theme most business software?

Maybe one day we will have business software that can be easily themed. Business software that we feel is ours. Business software that we fell that we own. Business software that is actually fun to use. Maybe one day.

Simple or feature rich? Usable or complex? It’s time to address a most perplexing question — Should you make your product simple and usable or feature rich and complex?

On one side are companies like Apple and 37Signals. Give the users simplicity, they say. On the other, Microsoft and most Linux apps. Give the user features, is their motto. And I? I say, hurrah for the long tail.

You see, both are right in their own way. Users want simplicity. Users want tons of features too, even if they arent going to use them all. Also, every user has a different ton of features that they want. Like Joel says, everyone wants 20% of the features, but each want a different 20%. So how do we go about solving this dilemma?

Above is a diagram that many of you might recognise as the Long Tail power curve. On the X axis are different features. It’s shown as a continuous axis for convenience. On the Y axis is the number of users using that feature. Its sorted such that more popular features are on the left. In red is what I will call the “hit” features that everyone will use. In yellow are the “niche” features that a small number of people will use.

The Apple philosophy is to have only the red, “hit” features that most want and leave out the rest to enable simplicity. The Microsoft philosophy is to have both “hit” and some “niche” features. They can serve more users this way, but compromise on simplicity. You see, unlike book or music sales, having more features has a side-effect on usability, so its not a simple question of just having more features.

Thats why your product must be hackable. I’m talking about hackable in the sense of extensible, of leaving room in the product to do things that it was not initially designed to do.

You can now design your product to implement the hit features, but leave it hackable so that the community can implement the niche features. Suddenly, your product can handle both. Not only that, users happy with the features in the product will be happy with the usability of the core product. Users wanting to get their hands dirty can do that too.

An example: I wrote before that Catalyst does only project management. Thats the simple and usable part. But Catalyst also has a REST based web API through which you can access the data in scripts outside the tool.

Someone asked me if Catalyst can integrate with source control. I was thinking about it when I realised that SVN has pre- and post-commit hooks. What if you could write a script which looks at the log message and if it found the text “Fixed Bug#xx”, took the Catalyst data via the API and set the corresponding task to done. How cool would that be? This is something that would be hard to do as a core feature, and will almost definately impact usability, but is great as a hack. And it wouldn’t be possible without leaving the data open for access via the API.

Another example: Export. The problem with export is that every tool has its own import format. Should we export to CSV? XML? Excel? There is no standard format that other tools can read. One solution is to implement a host of export formats for each tool. But using the API, you can write a script to get the data and save it in whatever format you want. What if you cannot write such scripts? Thats where the community comes into play. Only one person needs to create the hack and everyone else can use it.

Most companies attack users for using the product in ways it was not designed to be used. This is unfortunate because these are very passionate users. Don’t do it. Go a step further and make your product hackable. That way you can provide a great core experience and have the community extend it with cool hacks.

With all that, I’m happy to announce that once the beta period starts, I will be adding a hacks section to the site to document some of the cool stuff you can do with Catalyst. Happy hacking!

PS: In this article, I’m talking about hacking, not cracking. Dont confuse one for the other.