Startups Should Provide Maximum Value with Minimum Customer Effort

Image via Wikipedia

There’s a natural tendency with startup founders to offer solutions that are very customizable in an effort to meet everyone’s desires. This is a dangerous approach. Startups should provide maximum product value with minimum customer effort and customization.

Think about it: do you want to turn on a product and have it just work or do you want to spend three hours configuring things to see results? Of course, seeing results without customization isn’t always possible but it should be tried. In a similar fashion to progressive disclosure where advanced features are hidden by default, product value should be shown by default and then customization over time to get more value.

The next time a feature is proposed with nobs and dials to tweak it, ask the team how this feature could add value with little/no customization and what would that look like. Push hard to provide maximum value with minimum customer effort.

What else? What are some other thoughts around startups providing maximum value with minimum customer effort?

The Startup Tendency is to Over-Engineer the Product

Greg and another successful entrepreneur independently mentioned that startups have a tendency to over-engineer their original product. Over-engineering a product is done with the best of intentions: there’s a clean slate, more time for adding features since there aren’t customers, and an idealistic view of what the market needs and wants. Without customers to slow things down, find bugs, and submit requests, the pace of development is blazingly fast.

Startups need to spend more time with prospects and less time over-engineering the product.

This isn’t easy. Human nature, tending towards instant gratification, and the desire to build things, lends itself to writing more code and inventing more features, regardless of market demand.

The next time you add a feature without customer input, ask yourself the following question: will 80% of my future customers get value from this fuctionality?

What else? Have you seen the startup tendency to over-engineer the product?

What’s in a Feature Name

Image via Wikipedia

After the startup’s name and the product’s name (which should usually be the same as the startup’s name) the next most important thing to name is individual features/modules in the product. Coming up with great names for features is critical because that value carries over into several areas like:

• User experience / ease of use
• Marketing content, especially for search engine optimization purposes
• Other marketing content like blog posts, white papers, and social media
• Sales demos and support

The next time you go to name a new feature/module, stop and think through the many different ways it’ll be used and get feedback from a few people as to the best available name.

What else? What are some other reasons the name of a feature/module is important?

Consider Future Manual Labor When Adding New Features

Image via Wikipedia

When implementing new product features it’s important to consider future manual labor and support burdens. Often, there are several different options available with vastly different on-going implications. Personally, I can think of at least two features where we took the easier product engineering route and had north of 5x the manual labor to deal with due to the decision before we finally got back to upgrading the feature and did it the better way.

Ask yourself this: does spending an extra 50 or 100 engineering hours result in saving 250+ hours in the future? It might seem painful to allocate the software development time to the feature now, especially if there’s some quick and dirty solution, but future productivity could be mortgaged. Even though I’m an advocate of keeping things simple and getting the minimum viable functionality out the door, sometimes it’s important to consider the minimum viable and sustainable functionality.

What else? Do you consider future manual labor when adding new features?

Engineering Services Department Built on Product API

Image via Wikipedia

Earlier today I was talking to a successful SaaS entrepreneur and he was filling me in on some their latest initiatives. One of the things they had done that caught my attention was build an “Engineering Services” department that was staffed with software developers, but instead of working on the core application, they built small apps for customers using the product API.

Here are some benefits of an engineering services department:

• Acts as good training ground and pipeline for developers to start out and eventually move into core product engineering
• Provides a way to build product add-ons that don’t interfere with the main application roadmap
• Allows for customer development around potential new features that are originally spec’d as one-off customer apps

Personally, I like to invest resources in the core product and look to partners to provide value-added services. An engineering services department is such a complement it warrants its own place in a startup, especially once scale has been achieved.

What else? What do you think of having an engineering services department?

Minimum Viable Product or Minimum Acceptable Product

Image via Wikipedia

A recent post on the Signal vs Noise blog titled What happens to user experience in a minimum viable product? hits on an important point that I don’t think is covered enough: a minimum viable product doesn’t mean critical functionality is left out. The entrepreneurial tendency is to over-engineer the product in a vacuum and then realize that too many assumptions were incorrect. The minimum viable product is designed to go to the other extreme and build the simplest product that does something useful and then get user feedback as you iterate on it.

In some B2C cases, and many B2B cases, the market demands a minimum acceptable product. A minimum acceptable product is a minimum viable product plus a few (not too many!) niceties people expect in a quality product. The niceties could include items like the password reset option and other generally accepted features. A minimum acceptable product still should not be developed in a vacuum and driven with close customer input. One rule of thumb I like is that the minimum viable product should be built and launched in 90 days with the minimum acceptable product no more than 45 days after that.

What else? What do you think of minimum viable product vs minimum acceptable product?

Be Wary of “Check the Box” Features

Image via Wikipedia

Recently I was at Palmetto Dunes in Hilton Head Island, South Carolina. Palmetto Dunes is like a small village on the island with multiple golf courses, resorts, neighborhoods, etc. The core part of the area has a well-known tennis facility with over 20 tennis courts and several quality golf courses. What stuck out to me is that as part of the massive tennis facility and expensive golf course there was a tiny, 80s-era pool. It was clearly a “check the box” pool for the purpose of checking a box on different travel websites and marketing brochures. I’m guessing they don’t expect too many people to use the pool since the resorts and condo complexes have their own nice pools but it was still jarring to see it tucked away on the side near some infrequently used tennis courts.

The same “check the box” feature creep applies to software.

As an entrepreneur and product manager it is critical have a clear, consistent product vision and be extremely opinionated about what does and doesn’t make it into the product. When you start adding features to “check the box” it becomes abundantly clear to users and slows down future development with code debt. The next time to you go to implement a new feature that a competitor has or RFP requests, ask yourself the “check the box” question.

What else? Have you seen “check the box” features in products?