Today is a good day to code

Deciding When to Implement Features in a Startup

Posted: April 26th, 2011 | Author: | Filed under: Companies, Programming | Tags: , , , | No Comments »


Over the weekend I have been thinking about which features should be implemented and in what order. I realized that it didn’t make sense to try to prioritize each possible feature, as there are thousands of them, because that would take too long, and not necessarily result in a reasonable prioritization. I started to think up a framework for deciding which feature would be implemented when.

One of the first things to think about was the framework of the startup, or which development strategy the organization is using. In my case, we are using a lean-agile approach. This approach suggests that feature decisions should be based upon whether or not the implementation of a feature will affect positively any of the key metrics of the startup. An example would be, if you have a freemium product, conversions to paid from free.

What I would add to that philosophy, is that it isn’t enough that it move one of the metrics, but that it move the right metric for your startup at it’s current growth stage. If you are raising money, then gaining some sort of traction is likely more important than long term customer retention. If you already have product market fit, and you earn revenue through use of the product, then it makes sense to focus on making your software more pleasant to use.

To clarify this for myself, since I tend to obsess about usability a bit, I thought back to when I switched from PC to the Mac. I was telling myself that it was largely because I liked the usability of the product better, while this was true, it wasn’t why. I had just received a video camera at the same time and was playing around with various low-end PC video editing software, it basically sucked. Then I found out that the Mac came with iMovie. iMovie was far from perfect, but it was really good and gave me a capability that I didn’t have before. I could now edit long home movies easily, and burn them to DVD.

I realized that Apple got me to convert on a first order feature, and retained me on a second order feature. That is they gave me a capability that I didn’t have before, thereby converting me from a non-Apple user to an Apple user, and I created mainline revenue for them.

Apple has always been about this, when thinking about the iPhone 1, what did it do for me. Well, it didn’t have a ton of features, some of the ones that it did have were missing obvious things that it needed, like copy and paste, and it took a long time to get them, at first I didn’t understand why, but later it made sense. Apple was optimizing for that initial conversion, the product gave me the capability to use the internet and share photos in a minimal, yet useful way. That was what made me convert. If Microsoft had done that then I would have bought a Microsoft phone that day.

So what I decided was that I needed to figure out what the startup needed, right now we are fund raising and trying to acquire customers, so to me that means that we need to have features that get people to buy. Those would be first order, first priority features. Those things, that would make a material difference for the startup, and answer the question for the customer “what fundamental thing can I do with your product, that I can’t already do.” That is the question you must answer to get people to convert.

Second order features, the features that make your product nicer to use, are all features that are incredibly important. However, depending on your business model, you may be wasting time based on your organization’s goals working on second order features when you haven’t figured out the first order ones. Frequently when you see startups die, this is the reason. They are working on things like performance, or some trick usability thing that is really awesome and hard, so it is sucking up time, meanwhile you aren’t adding users because you have failed to answer the critical question. Maybe you know what your product will do in the end that is transformative, but your prospective customers don’t know. You must work on transformative, game changing, disruptive features first.

Successfully Scaling an Organization

Posted: July 30th, 2010 | Author: | Filed under: Companies, Management | Tags: , , , , | 1 Comment »

Startups face a myriad of issues in the beginning.  They must find a way to become successful, they have to find a way to make sure that their product scales to meet the demand, they need to find ways to raise money, they need to be ever-ready to pivot into another aspect of their target market.  There are so many issues to think about that one often seems to get left behind.  The question of how do you scale your startup people wise?  What do you do to make sure that you have the right talent with the right levels of responsibility?  How can you ensure that you are retaining and challenging your best talent?

The above questions are a devil of a problem that creeps in fairly suddenly and often without announcing itself.  The result is clear enough, most of us have seen it before.  Reduced output, fewer, and fewer new product ideas bubbling up, or at least, fewer and fewer product ideas bubbling up to the executives.  No risk taking from anyone in the company, way too much time spent in meetings.  Most of the prevailing wisdom is that you just have to stay small, do not get large.  I completely agree, that it makes sense for companies to stay small if possible, but sometimes you can’t stay small.  I would argue that it simply isn’t possible for a company like Facebook to be small, the demands and requirements from their customers require lots of construction and cohesive solutions.  What should they do?  Should they break themselves into separate companies? Breaking up is typically not a solution that makes sense.

I’m not certain that I have the answers to these questions either, but I have experienced these issues in most of the places I have worked.  In all of these places, the intent is always good, people want to overcommunicate, they want to make sure that everyone is heard and that all ideas are considered.  Being good listeners and accommodating a marketplace of ideas are what all of the management books talk about.  The issue is that when a company gets too large, the sheer time it takes to do that becomes prohibitively expensive.

The solutions that I have seen put forth, and I intend to use is initially to keep teams small and allow those small teams to retain ownership of some critical pieces of the solution.  In addition to that I want to keep people building by allowing time to develop along their own relevant interests and for them to sharpen their pitch skills by presenting to other teams and gathering feedback.  That will hopefully help the teams grow, and will make it clear who the people with leadership skills are, and allow them to try and occasionally fail in a safe way that keeps the company moving forward.

Having small teams and keeping specific responsibility residing within those teams will help maintain accountability, minimize meetings, and reduce communication overhead, but it requires a lot of work from the vision holders.  Not only do they have to have a stellar and clear vision, they have to have communicated that clearly to each and every person working in the company.  That works fine for a very small company, but when you get larger it is harder and harder to make sure that every understands the goals and dreams of the company.

Funny enough, most of the scaling techniques that are applied to large application servers works well in scaling engineering organizations.  Shared nothing, separation of concerns, etc…  The issues begin to crop up in organizations that are not engineering organizations, and among groups who are not highly intelligent, skilled and motivated like engineers.  I still believe that a company can successfully scale with lower skilled staff, but it requires a concerted effort to decentralize the operations to the point where each small group operates in a largely independent fashion and the company still achieves its goals.

I believe that the answer lies * of course * with technology.  Were senior management to embrace some of the social communication techniques that most teenagers employ, managing large groups of independent teams wouldn’t prove to be so daunting and they could directly provide leadership to a wider group.  It would require for them to work non standard hours, and work longer ones where they are more accessible, but I believe that it should be possible to run a highly efficient and decentralized organization where everyone is actively contributing.

* Update *

Ben Horowitz wrote a great post on how to scale a company.