Brad's Books and Organizations

Books

Books

Organizations

Organizations

Hi, I’m Brad Feld, a managing director at the Foundry Group who lives in Boulder, Colorado. I invest in software and Internet companies around the US, run marathons and read a lot.

« swipe left for tags/categories

swipe right to go back »

Substance vs. Appearance

Comments (8)

I had dinner tonight at the Defrag pre-conference "Future of Email" gathering.  It was a great crowd that included a bunch of smart people working on interesting email / communication / collaboration stuff.

Around dessert, I got into a deeper conversation about features.  We were talking about one of the greatest challenges of any software company – how to decide what features to leave out of the next release of your product.  We immediately went deeper than the typical "do what your users say they want" paradigm as anyone that has sold software knows that there is a huge difference between "what your users say they want" and "what your users will pay you for".  This is especially challenging if you have a free, or freemium, model.

We concluded that there are two dimensions.  The first axis has appearance at one end and substance at the other.  The other axis has "what your users say they want" at one end and "what your users will pay you for" at the other.  Using this two by two matrix can help you prioritize features more clearly, while recognizing that you often can’t really determine what users will pay you for in advance.

As I reflect on this, it occurs to me that certain types of users are more interested in appearance while others are more interested in substance.  This will influence where your priorities will go as you have to understand what actually drives your users’ adoption behavior in the first place.

Ok – this now feels likes it trending toward being too theoretical all of a sudden, but the challenge of priorities is increasing in importance as companies operate in a more cash constrained world.

  • http://www.emotionai.com Ian Wilson

    I think you bring out a very important point here, complexity, or the lack of it. If you build “a” product with “a” set of features it will appeal to “a” set of users, which may not be a large one. What we are currently not geared up to is building products that can adapt to each user (or at least a reasonably large set) beyond very simple controls.

    If your product or service were reasonably adept at adapting to its users then you might be able to obviate some of the problems you are talking about. The key for a business then would be in understanding how to build these capabilities elegantly and cheaply.

    • http://www.feld.com Brad Feld

      Very well said. The idea of software adapting to users, especially when all the data and processing is in the cloud, is so incredibly attractive while being simultaneously elusive. I just spent 15 minutes changing 150 Google alerts from “email” to “feed” so I could get them via RSS. Google Alerts should have figured out what I was doing after the 10th manual change and offered me the option of changing them all. But it didn’t. Simple things like this would make software so much more useful.

    • thompsa6

      Ian I think you are spot on. Consider the point of view of a community platform, when I start building user groups, community content, etc., etc. I want the app to make this super easy for me as I'm learning the ropes. Give me patterns of interactions: create a user group from a pattern of providing customer support, create a blog from a generic blog pattern, etc. But then as I become a more experienced user give me additional options and make advanced features available to me. Pay attention to the content and user groups I've created in the past to help make the work flows simpler: do you want to change the structure of what a blog post is for your blog? (give me the choice of using a custom blog data structure I've created before), do you want to setup special rules for managing content within your customer support group? (give me suggestions of how others in the community have done this or even suggest rules I've customized in the past), etc.

      The other cool thing with this type of approach would be attribution. If I am a very active advanced user within the application and my activities are suggested to others as patterns or best practices, then give me credit in some way. Obviously nothing that takes away from the software but something that helps build my reputation and personal brand.

  • http://www.barketingmlog.com Jeff

    The next step would be take user group information cross platform. I.e., behavior (such as changing email alerts to RSS feeds) on Google Alerts could not just automate the rest of the process for you, but it could take that behavior knowledge and apply it to or inform a similar situation on another Google platform (or another site all together).

  • John May

    Something that everyone has learned is that you don't always get it right. What is often more important is how to react. One of the key aspects of agile development is the ability to re-prioritize on a two week basis and ship in two weeks if needed. The interaction of feedback in the loop on a regular basis enables you to mitigate risk of builing something that is either not right or does not make you money.

    This development model is a continuous process similar to continuous improvement so well implemented by the japanese structures and modeled by Toyota. Consider requirements to be “Just in time” elaboration as a lot of companies spec out a whole lot and see it change. Eliminate waste in the process and building to the needs moves right to the top of the list every time while putting your time to development rather than a lengthy process. This helps to allow your company to turn on a dime and do it at less cost than your competition. Sure seems like a sure fire way to stay ahead of competition and take advantage of new opportunities. As we struggle in this economy, these aspects become paramount for survival.

  • http://www.BestTimeTools.com Michael Wilkes

    One of my favorite sayings is “Don't confuse activity with production.” When applied to this topic, it would have to morph a bit to become “Don't confuse a visible increase in features with the ability to get more work done.” The balance between pleasing users with new features and pleasing the people who write checks with increased productivity is an interesting dance.

    Years ago we tried to launch a product based on *great* feedback from the user community. Wrote the brochure, shrink-wrapped the product, marched off to the shows only to find out that the people who use the product are not the people who buy the product. Unfortunately, we need to catch and hold the interest of both!

  • Jay

    I understand the one axis, users saying/paying. But i am not sure i get the significance of the substance-appearance axis. You know an example would REALLy help.

    • http://www.feld.com Brad Feld

      Ah – examples. I’ll try to weave on in the next time I post about this.

  • http://intensedebate.com/people/bfeld bfeld

    Ah – examples. I’ll try to weave on in the next time I post about this.

  • Jeff

    The next step would be take user group information cross platform. I.e., behavior (such as changing email alerts to RSS feeds) on Google Alerts could not just automate the rest of the process for you, but it could take that behavior knowledge and apply it to or inform a similar situation on another Google platform (or another site all together).

  • Michael Wilkes

    One of my favorite sayings is "Don't confuse activity with production." When applied to this topic, it would have to morph a bit to become "Don't confuse a visible increase in features with the ability to get more work done." The balance between pleasing users with new features and pleasing the people who write checks with increased productivity is an interesting dance.

    Years ago we tried to launch a product based on *great* feedback from the user community. Wrote the brochure, shrink-wrapped the product, marched off to the shows only to find out that the people who use the product are not the people who buy the product. Unfortunately, we need to catch and hold the interest of both!

  • http://intensedebate.com/people/bfeld bfeld

    Very well said. The idea of software adapting to users, especially when all the data and processing is in the cloud, is so incredibly attractive while being simultaneously elusive. I just spent 15 minutes changing 150 Google alerts from “email” to “feed” so I could get them via RSS. Google Alerts should have figured out what I was doing after the 10th manual change and offered me the option of changing them all. But it didn’t. Simple things like this would make software so much more useful.

  • John May

    Something that everyone has learned is that you don't always get it right. What is often more important is how to react. One of the key aspects of agile development is the ability to re-prioritize on a two week basis and ship in two weeks if needed. The interaction of feedback in the loop on a regular basis enables you to mitigate risk of builing something that is either not right or does not make you money.

    This development model is a continuous process similar to continuous improvement so well implemented by the japanese structures and modeled by Toyota. Consider requirements to be "Just in time" elaboration as a lot of companies spec out a whole lot and see it change. Eliminate waste in the process and building to the needs moves right to the top of the list every time while putting your time to development rather than a lengthy process. This helps to allow your company to turn on a dime and do it at less cost than your competition. Sure seems like a sure fire way to stay ahead of competition and take advantage of new opportunities. As we struggle in this economy, these aspects become paramount for survival.

  • http://intensedebate.com/people/thompsa62829 thompsa62829

    Ian I think you are spot on. Consider the point of view of a community platform, when I start building user groups, community content, etc., etc. I want the app to make this super easy for me as I'm learning the ropes. Give me patterns of interactions: create a user group from a pattern of providing customer support, create a blog from a generic blog pattern, etc. But then as I become a more experienced user give me additional options and make advanced features available to me. Pay attention to the content and user groups I've created in the past to help make the work flows simpler: do you want to change the structure of what a blog post is for your blog? (give me the choice of using a custom blog data structure I've created before), do you want to setup special rules for managing content within your customer support group? (give me suggestions of how others in the community have done this or even suggest rules I've customized in the past), etc.

    The other cool thing with this type of approach would be attribution. If I am a very active advanced user within the application and my activities are suggested to others as patterns or best practices, then give me credit in some way. Obviously nothing that takes away from the software but something that helps build my reputation and personal brand.

  • Ian Wilson

    I think you bring out a very important point here, complexity, or the lack of it. If you build "a" product with "a" set of features it will appeal to "a" set of users, which may not be a large one. What we are currently not geared up to is building products that can adapt to each user (or at least a reasonably large set) beyond very simple controls.

    If your product or service were reasonably adept at adapting to its users then you might be able to obviate some of the problems you are talking about. The key for a business then would be in understanding how to build these capabilities elegantly and cheaply.

  • Jay

    I understand the one axis, users saying/paying. But i am not sure i get the significance of the substance-appearance axis. You know an example would REALLy help.

Build something great with me