Principles for First-Use Tools


Even as we’re working out the potential features for the next version of Visual Studio Express, we’re looking beyond that. Express has done an amazing job (5M downloads!) of getting development tools into the hands of many people. The feedback we’ve gotten has been amazing and satisfaction rates are through the roof. But we know we have to do more.

There’s a tension on the Express products: either we can add more professional-style features, or we can focus on keeping concept count low. We can’t do both. Based on what the registered users have told us in a survey that Dan Fernandez recently ran, I’m opting to push for keeping concept count low so the products can remain very approachable.

This led me to start to think about a broader set of principles for my team. I’m interested in feedback:


  • Hobbyists are doing this for fun. Our competitors are things like television, Xbox, and iPods, not so much other development tools. When we are looking at enthusiasts, we need to ensure we’re focused on captivating them with fun things to do, rapid rewards and few frustrations. Showing off to your friends is a nice added bonus.
  • Simplicity and approachability are critical. We’re not looking at a customer base that will spend an hour learning how to navigate the Solution Explorer or the Toolbox: in about 20 minutes if they haven’t had the endorphin rush that comes from getting something done, they will do something else and we’ve lost them forever. That means we need to keep acquisition time as close to zero as possible (i.e. reduce big downloads with many dependencies) and keep our efforts targeted at people with little or no training in programming.
  • The next step needs to be in sight. People will grow as they use the product more and the next step always needs to be in sight and obvious, whether it’s another learning module, a community site to get another starter kit, or the next Microsoft SKU to upgrade to, we need to make discovering the next thing to do simple and fun.

Comments (4)
  1. Why not keep the concept count low and allow others to extend it using add-ins?

  2. johnmont says:

    Excellent point and there are cases where that will work very well and I’m planning on doing quite a bit of that. Sometimes the work involved in building these add-ins is high. For example, with ADO.NET and LINQ we have two rather different ways to access data. For upward compatibility with the higher-level products, we need to have runtime and language support for both in every Express product. If I have both, I’ll be shipping two slightly different data access methods and that will definitely confuse many of the newcomers to .NET, Express, and programming. So to reduce concept count, I’d pick just one and ship it by default. I could ship one in the box and build an add-in for the other, but the cost is huge. So which one should I ship? Why? Also, which set of customers will be upset if I choose one over the other?

    Now imagine that set of questions applied to about a bazillion features and you have a sense of why I need some set of guidelines to help guide the decision making.

  3. orcmid says:

    I’m liking this.  I think contributors are getting to hands-on quickly and also finding steps that won’t discourage someone, while leaving plenty of room for further exploration as well as moving to new experiments, experiences, etc.

    In short, yes.

Comments are closed.

Skip to main content