Category: Product Mgmt

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?

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?

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?

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?

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?

The idea of a minimum viable product for startups has made the rounds over the past few years. One area that needs more attention is around delivering the minimum viable new features in existing products. Just because the product is now successful doesn’t mean that the innovation around new functionality needs to slow down and revert to a must-get-it-perfect-the-first-time mentality.

Here are some ideas when considering the minimum viable functionality for new features:

• Lock the functionality down to only employees and key customers to test features while it is being developed
• Push code to production (if it is isolated) while it’s being developed so that people can start giving feedback
• Identify a new feature that can be built in one to two weeks — if it takes longer than that it is probably too broad or you’re using antiquated technologies
• Remember that feature usage is oxygen for a product and that things shouldn’t be developed in a vacuum

Developing the minimum viable new feature functionality is the same mentality as building a minimum viable product and should be employed by agile startups. There’s a tendency to slow down once things become more established and it’s important to fight it.

What else? What other thoughts do you have on delivering the minimum viable functionality for new features?

Products with great functionality and strong form/design are often the most successful, but they don’t usually start out that way. For many entrepreneurs, especially with B2B products, getting the function right should precede getting the form right. The idea is that you want to solve the problems as efficiently as possible, even if the UI isn’t as nice as it could be done with more resources or time. Some entrepreneurs attempt to get the design right before users are even on the system. Users are oxygen for the product and need to be part of the design and feedback process so that it isn’t built in a vacuum.

Here are some ideas when thinking about product form and function:

• Function needs to come before form
• Form is important for B2B products, and even more so for B2C
• More and more enterprise products are taking UI inspiration from B2C web apps
• Consumer web apps are raising the design bar for business apps
• It is often more difficult to find front-end product designers that back-end developers

Product form and function are difficult to do well but function is more important. Form takes a special talent with a graphical eye as well as strong user experience understanding.

What else? What are some other ideas when thinking about product form and function?

Gathering and organizing product feedback from constituents like customers, prospects, analysts, sales reps, support reps, and more can be a real challenge. I like to recommend two different strategies depending on the stage of the startup:

• Seed Stage Product Feedback Strategy – a simple Google Spreadsheet with columns like Idea, Comments, URL, Done, and Proposed By goes a long way. The goal is to have something quick and dirty that allows everyone to see the ideas and add their thoughts. Each month a sheet in the spreadsheet should be renamed to archives and another sheet should be added so that things don’t get too cluttered. Customers and prospects don’t have access to the spreadsheet but all employees do have access.
• Early/Growth Stage Product Feedback Strategy – a combination of a simple Google Spreadsheet and a formal app like UserVoice. UserVoice would be used by customers and employees. The Google Spreadsheet would be similar to the seed stage spreadsheet but it would be exclusively managed by the product manager. Every month the product manager would solicit input in person from the key constituents as well as ideas in UserVoice to come up with the road map. The process is more formal but still collaborative and agile.

Gather and organizing product feedback is critical for the success of a startup. Using these simple approaches provides for a scalable strategy.

What else? How do you gather product feedback in a startup?