Category: Product Mgmt

With a clean product slate as a startup it’s easy to iterate and add functionality quickly. The key to remember, especially with customer driven development, is that product development should be paced with customer input. It’s too easy to keep adding features without giving adequate time and effort to solicit feedback.

Keep these in mind when considering the pace of development:

• Maintain a strong opinion of the product direction independent of prospects, analysts, customers, and competitors
• When considering feature requests, always ask if it is applicable to 80% of your desired customers
• Don’t be afraid to remove features or unnecessary complexity from the product if they aren’t adding value (this is a delicate area)
• Keep a good pace of development and make sure clients know about new features through blog posts, dashboard updates, social media, and newsletters

My recommendation is to pace product development with customer input while maintaining a strong internal product opinion.

What else? What are some other things to keep in mind when considering the pace of development?

One of the co-founders of a startup should take ownership of the product management role. Product management encompasses everything from customer discovery, feature planning, roadmaps, QA, strategy, wireframes, documentation, and more. After building several commercial products personally, as well as helping other startups, I’ve seen a number of mistakes first-time product managers make repeatedly. Here are a few of those mistakes:

• Overcomplicating the product (I still have a tendency to do this) knowing that Voltaire’s quote “the perfect is the enemy of good” holds true
• Waiting too long to deploy changes out to the production server (startups should do continuous deployment or at least daily deployment otherwise it leaves room for a culture of monolithic development)
• Inconsistent capitalization in button and link labeling (e.g. “Edit user” in some places but “Edit Object” in others)
• Not appreciating that window dressing and subtle niceties in a UI contribute toward the user experience
• Creating complicated interfaces that don’t employ progressive disclosure of advanced functionality

My recommendation is for first-time product managers to pick up a book like Designing Interfaces and really be a student of the art of building a great product.

What else? What are some other common mistakes for first-time product managers?

Continuing my post from yesterday that Usage is Like Oxygen for Ideas in Products I want to talk a bit more about the endless debate on when to push out new product features. Product, in this context, is Software-as-a-Service (SaaS) applications on the web. Generally, with installed software, new features need to be tested 10x more thoroughly before shipping as there is a much higher cost to make a mistake. As for SaaS products, here are some reasons to push out features fast and frequently:

• No feature survives intact with contact in the real world
• Customers appreciate innovation, even if it isn’t always perfect
• Customers provide more input when they see a product is actively enhanced vs one that doesn’t change often
• Programmers have a tendency to overcomplicate features, so pushing out bite-sized chunks forces a simplification of the functionality

Now, how is fast and frequently defined? There’s a movement to do continuous deployment where every piece of code checked in goes straight to production if all the tests pass (see IMVU pushing out code 50 times a day). We don’t do continuous deployment but we do look to push code anywhere from daily to bi-weekly depending on the maturity of the product and the impact of the feature. My recommendation is to err slightly on the side of pushing out too fast knowing the trade-off that some features will not be enough for users, but will provide a strong foundation for feedback.

What else? What are some other considerations in pushing out new product features?

Building high-quality software is still more of an art than science, especially with the preponderance of different opinions to accomplish even the simplest of functionality. With the rise of open source software, great web development frameworks (e.g. Rails), and lighter languages (e.g. Ruby) it is cheaper and faster to build web applications. It’s hard to make an app easy. It really is difficult.

One of the best ways to do user testing is to grab a person who hasn’t used the software before, give them a gift certificate or pizza, and ask them to accomplish tasks in the product. That’s it. Don’t ask about the color scheme, positioning of icons, or arrangement of navigation links. Simply ask for some deliverables and get out of their way.

A critical part of this process is to not lead them on asking “what did you think about X” while they’re in the middle of the process. Too often product managers and co-founders are so excited about the product that they can influence the activities of the tester. It is best to make the desired tasks black and white and put them in front of the tester and have he or she go to town.

What else? What other recommendations do you have for user testing?

One area that first-time entrepreneurs often give little thought to is how they are going to position their product. Generally, the desire to start a company and build a product is driven by the goal to “scratch an itch” and fix a problem or grab an opportunity. I’d like to divide product positioning into two super simple categories:

1. Little to no learning curve and you eventually grow out of it
2. At least some learning curve and you grow into it

Yes, there are many more nuances than this but for many entrepreneurs this provides a simple framework with which to use, especially for the many 37signals inspired simple web apps out there that fall into category 1. Once you’ve chosen a category, next you should find a product that falls into the other category relative to your product. Typically I’m against paying too much attention to competition and instead focusing on customers and prospects, but the competition works well in this case. Now with a deep understanding of the competitor that falls into the other category, make a list of the differentiation points that serve as a transition between the products and use that as a guide when building the product.

What else? What other points would you add with regard to growing into and out of products?

At today’s Atlanta technology community lunch the featured guest was Promod Haque, one of the most famous VCs in the world. One of the stories that stood out to me was when Promod recounted when it was first emphasized to him that customer intimacy was a major key to success.

10 years ago Promod was chairman of a company where the CEO was actively recruiting a VP of Engineering. The VP of Engineering was almost ready to join the company but stipulated that he had to talk to the chairman in person first. Promod, curious about this request, met with the prospective VP of Engineering, and was posed one single questions: is there money in the budget to hire a VP of Product Management? After saying, yes, of course, that they were actively recruiting a VP of Product Management, Promod inquired as to why this gentleman was concerned. The prospective VP of Engineering said that he can build anything but that he needs a VP of Product Management that is truly connected to the customers and can distill down what needs to be done. The yin to his yang would be critical to the success of the company.

My recommendation is for one of the company co-founders to own product management and make it one of his or her top priorities. Product management is one of the more difficult skills to hire for and is best done by someone who is truly passionate about the product and builds great rapport with customers.