Category: Product Mgmt

Sometimes we get the urge to build a little app on the side to solve a certain problem that isn’t as core to our main product (like billing). Fight the desire, we must. Building a small app outside the core product introduces a host of challenges like:

• The fresh excitement to build an app from scratch wears off when no one wants to maintain it on a day-to-day basis
• Testing and QA won’t be as rigorous due to higher priorities
• Interface changes won’t be implemented consistently due to the separate code base
• Server monitoring and administration infrastructure won’t be as thorough due to unique aspects of the architecture that are different from the main app

My recommendation is to avoid making little apps when at all possible as maintenance of them becomes a serious challenge. Unfortunately, they won’t be given the necessary on-going attention.
What else? What other thoughts do you have on making little apps vs more modules in the core product?

Communicating new product features to clients, especially in a fast moving SaaS application, is critical to help them maximize the value of the application and to appreciate that the monthly or annual fees are not only for the current product but also for enhancements. Many customers will be comfortable with the current functionality, or have a feature or two they really crave, but some customers, especially the raving fans, want to stay abreast of all the latest functionality. It’s important to have a multi-pronged communication approach to try and educate as many clients as possible without being overly intrusive.

Here are a few communication strategies:

• Write a short blog post introducing each new feature (save it mostly for features and not little tweaks)
• Tweet the blog post and provide a Facebook Page Wall post
• Include a link to it on the homepage of the product or on the sign-in screen (this is the most effective as you have a captive audience)
• Include the content in a monthly newsletter
• Recap the major new features of the past 12 months at the annual user conference

The key is to communicate the information to users currently in the system, on Twitter/Facebook, and so and so forth. One size doesn’t fit all.

What else? What are some other ways to announce new product features to clients?

One of the tactics we employed early on was taking a page out of salesforce.com’s playbook by sending an opt-in daily email to users of our app highlighting results. What I mean is users get spoon feed an email report detailing all the visitors and prospects that have been recently active. This type of feature has several benefits:

• Removes friction with more passive users so that they see value from the product on a regular basis
• Makes it easy for the stakeholder to forward the results to his or her boss
• Helps keep the product top-of-mind with users while encouraging them to use the app more frequently by clicking through to see more details
• Sets the tone for many of our users to be one of the first emails they look at each day because the data is so valuable

My recommendation is for entrepreneurs to provide daily or weekly metrics to their customers to help drive product value and customer satisfaction.
What else? What other benefits are there for showing app value with regular results emails?

The web app user experience is one of the most critical parts of a successful startup. It doesn’t matter how much funding, lead gen spend, or passion you have if users don’t have a great experience. Here are some common user experience mistakes:

• Too much work to get value from the system (give users value as quickly as possible)
• Inconsistent navigation controls making it difficult to traverse through the product
• Programmer-centric naming of product modules and functions as opposed to using the user’s terminology
• Inadequate attention to detail (get your most meticulous employee or friend to analyze the app)

Pay attention to user experience and users will pay attention to your app.

What else? What are some other common user experience mistakes?

Many times I’ve heard an entrepreneur say they can’t compete with a larger, well funded competitor due to the number of software developers in their startup vs the competition. Immediately, I like to remind them that the speed of application development is correlated with the size of the customer base for most companies. That is, as the number of customers on a platform grows the pace of new feature development and expansion slows for several reasons:

• More process and QA is introduced
• More time is spent on scaling the app’s infrastructure
• More bugs and edge cases are found
• More people are involved in the product management decision making

Startups often win by moving faster than the competition, staying closer to the customer, and timing the market. Startups are better off going deeper in a specific area and using that as differentiation rather than trying to be as broad as another company with many times the resources.

What else? What other thoughts do you have on speed of app development vs size of customer base?

One aspect of product management that took me many years to appreciate is the potential support burden of new features. When developing a new product, even in the first 12 – 24 months, it’s so easy and quick to implement additional functionality there’s a tendency to add new features without regard to longer term implications. The most important aspect of product management is to be opinionated about what goes in, and doesn’t go in, the product.

Here are a few tips when considering the support burden of new features:

• Pay particular attention to anything that allows custom code like HTML, CSS, or scripting as these are challenging to support
• Watch for difficult user experience interactions like multi-select conventions
• If you find strong contention internally for how a feature should be implemented it could be equally challenging for users to use regardless of how it’s done
• Consider if the feature should be part of a specific plan or offering (e.g. more expensive plan or add-on due to the complexity)

Implementing new features should not be done in a vacuum even if you are opinionated about the product. In addition to curating the product’s functionality, the complexity and support burden should also be considered.

What else? What other tips do you have when considering the support burden of new features?

One of the nice problems to have as a startup grows is scaling the web app. Scaling the web app encompasses not only the back-end infrastructure but also the user interface components as well. We like to take the approach of providing oxygen (client usage) to the new features and improvements as quickly as possible and iterate from there, resulting in scaling rework once the need arises.

Here are a few tips to keep in mind when scaling a web app on the front-end and back-end:

• Consider caching the values of any SQL COUNT() calls as new columns in the database updated asynchronously on a schedule (we’ve encountered this many times resulting in performance hits until they are corrected)
• Be wary of database-level full-text searching or advanced searches of structured information as specialized indexers like Sphinx and Lucene are much better suited
• Any user interaction that takes more than five seconds should put in a background job that triggers a message to the user when complete
• Consider the user experience when something like a drop down or chooser has a large number of fields (e.g. once a drop down has more than 15 choices have it change to a type-ahead selector or some other input type)
• Implement an aggressive archiving plan early of for any data that isn’t critical and can accumulate over time as it is harder to take things away later as opposed to providing more (e.g. how much time certain data is available before it is purged)

These are just a few of the items to be cognizant of when scaling the front and back-end of a web app.

What else? What are some other tips for scaling?