Category: Product Mgmt

Continuing with yesterday’s post Repeatable Customer Acquisition Process to Raise Money, I wanted to address the first question that I’ve received several times over the last month: What are some best practices for incubating a product in a services company? Personally, I have more experience building product companies compared to service companies but I did the transition with my first company.

Here are some best practices for incubating a product in a services company:

• Don’t have employees split time between their traditional services and product work — inevitably the services work will continue to get done because it pays the bills and enough progress won’t be made on the product
• Dedicate a product manager/jack of all trades and a software developer to work on the product full-time — these two people should complement each other well and have the capabilities to do everything necessary to get the product off the ground
• Consider making the product a separate company so that it can receive the dedicated attention it needs
• Employ lean startup best practices throughout
• Have everyone involved read Getting Real by 37signals – the best web app product management book available

There’s no sure fire way to make the product successful but by following some of these best practices the chances of success increase substantially.

What else? What best practices do you recommend for incubating a product in a services company?

In the most recent issue of Inc. Magazine there’s an article about the Tumblr founder titled  The Way I Work: David Karp of Tumblr that mentions one of the things I’m a big proponent of — dark features. The idea of a dark feature is that it is a feature added to a webapp that only certain users like your employees and a few early adopter customers can see. Web technologies are great in that it is easy to try out new functionality in production while locking it down until it has been refined and polished.

Here are a few benefits of using dark features as a product management best practice:

• Encourages broader testing of new functionality by stakeholders
• Feature testing is done in the production environment providing for a greater chance that more edge case are found
• Improves engineering by promoting new functionality to production more frequently for real-world feedback (feedback is oxygen for a product)

My recommendation is to incorporate dark features as a product management best practice.

What else? What do you think of incorporating dark features in the development process?

Most startups should pick one or two things and do them extremely well. I’ve seen more startups fail trying to be all things to all people than ones that have picked a narrow set of features and gone deep with the functionality. Now, there is a place in the market for products that are broad but lack depth, especially in the small-to-medium sized business segment. It’s important to make a conscious decision when developing the product around the direction and opinion of the application.

Let’s look at a few examples:

• Bronto – great email marketing platform with a deep feature set targeted towards online retainers (large but specialized market)
• HubSpot – leading inbound marketing platform geared towards small businesses under 10 employees with solid features, but not as deep as specialized tools like SEOmoz.org or AWeber
• Salesforce.com – largest SaaS CRM provider by far with a deep salesforce automation feature set and massive ecosystem of third-party apps facilitating a best-of-breed approach

My recommendation is to make it clear early on whether you’re going to go narrow and deep (preferred) or broad and shallow (more difficult).

What else? What do you think about going deep or wide with the product feature set?

This afternoon I had the opportunity to listen to two entrepreneurs pitch their new product and company at my office. The entrepreneurs are talented software developers and have been building an app for the last four months. After some quick catching up I asked them to do a short product demo as I always want to see the technology as much as I want to learn about the business — I’m a product geek at heart.

As you might have guessed, the inevitable happened: the product demo failed due to our firewall blocking certain ports. Entrepreneurs should always prepare for product demo failure. Here are some tips for preparing for a product demo and if it fails:

• Have screenshots of key app functionality ready to show in a simple PDF or Google Presentation
• Bring handouts in the event the projector doesn’t work (yes, dead trees come in handy once in a while)
• Don’t spend too much time trying to get the demo to work — the goal of a meeting is to develop interest for a next meeting so focus on building rapport
• Apologize for the demo not working and make a note to follow-up with instructions on how they can test it on their own

Product demo failures are a part of entrepreneurship. Take the failure in stride and still make the most of the meeting.

What else? What are some other tips around product demos and product presentation failures?

One of the simplest, cheapest, and most effective user experience and product testing things you can do is with Skype screen sharing. It works so well because the person on the other end shares their screen, and with Skype you can’t take control of their desktop, so you can only watch what they do. The key is to ask them to accomplish tasks on a generic level (e.g. create a new blog post) and sit back and watch them work. You’ll be amazed at what you notice and value you gain from the questions they ask — they don’t have the same tunnel vision you do being so passionate about your application.

Here are some quick tips for user experience testing with Skype screen sharing:

• Don’t share your screen with them — make them share their screen and walk through things on their own while you watch
• Ask them to accomplish tasks and take at least 60 seconds after they get stuck before helping — them getting stuck and trying different options is great UI feedback
• Once you’ve had them go through different tasks, then take them through the product and go over the most important features describing the functionality — this is a cathartic exercise in that talking through it out loud with someone who hasn’t seen the app before helps you personally see new issues
• Do this with a new person on a weekly basis and then move to monthly as the product matures

One-way Skype screen sharing is the digital equivalent of one-mirrors for user testing — only it is free and significantly easier. My recommendation is for entrepreneurs and product managers to incorporate this into their product development process.

What else? What are some other tips for user experience testing with Skype screen sharing?

Two weeks ago I had separate conversations with different entrepreneurs about how they prioritize research and development in their companies. Each conversation was brought up independently but the respective entrepreneur lamented how as their companies had grown the speed with which new features were released slowed down — it was now hard to make time for R & D. Customers were requesting enhancements to existing features, the architecture team wanted to improve back-end items, and the support team wanted to make certain processes easier.

One entrepreneur was thinking of going to an 80/20 model where engineers spent 20% of their time on new features and 80% of their time on existing requests. The other entrepreneur was thinking of dividing the engineers up into different teams where one team would only be new features and the other team would working on existing functionality. There’s no easy answer.

Here are a few best practices when prioritizing time for new features:

• Continually re-iterate that every hour spent on a new feature is taking time away from some other change, and that that is OK
• Remind all stakeholders that you can’t make everyone happy but that by having a strong vision and opinion for the product you’ll minimize time spent on features that are too narrow in focus
• Work with sales, marketing, support, operations, and engineering along with soliciting input from customers and partners during the time allocation decision making process

Prioritizing time for new R & D relative to other requests is hard. The best thing to do is to make the necessary time, over communicate, and deliver great results.

What else? What other thoughts do you have on prioritizing time for new research and development?

We like to push out new features fast. Very fast. On a typical day we might push out four updates of our software to production. Now, we don’t do continuous deployment but I’d like it if we did. Do we make mistakes? Yes. The great thing about our mistakes is that they are small, because we push the changes out in bite-sized chunks. With small mistakes come small issues that we can fix quickly. The more complex the change the more complex the fix.

We do a combination of code reviews, human testing, unit testing, functional testing, and continuous end user experience monitoring. This doesn’t catch everything but it catches the vast majority of issues and always ensures the core system works. We find that customers prefer fast product innovation with minor hiccups to much slower product innovation, and still have minor hiccups. To err is human, and we’re comfortable with that.

My recommendation is to move fast and build that into the core competency of the business. Startups win by staying closest to the customer and moving fast.

What else? What do you think about pushing out features fast?

A friend of mine from college joined salesforce.com (yes, all lowercase is the proper spelling — it’s a late 90s dot com thing) right after he finished business school and has been there for several years. At last year’s Dreamforce conference I was asking him about their engineering department and how they structure on-shore/off-shore software development. He said all the R&D is done in San Francisco in a pod-like setup similar to yesterday’s post on pods at Rackspace.

Here’s some info on pods in R&D at salesforce.com:

• There are roughly 28 different teams/pods
• Each team focuses on a specific module or piece of a module in the product
• The pods have one product manager, roughly five engineers, and a QA person
• Each pod does a daily stand-up scrum meeting led by the product manager
• The large number of product managers allows each of the small teams to stay close to the customer and minimize the telephone game where details get lost in layers of bureaucracy

The pod approach makes it easy for salesforce.com to scale their R&D by adding more and more pods as the business grows while staying agile and innovating quickly.

What else? What do you think of the pod approach to scaling R&D?