David Cummings on Startups

Category: Product Mgmt

  • Two Schools of Thought on Scaling B2B SaaS App Data

    Scaling the data storage for B2B Software-as-a-Service (SaaS) applications typically falls under two schools of thought: one or more fully-contained accounts per database or specialized multi-tenant sub-systems that handle certain types of data. There are pros and cons to each approach.

    Fully-Contained Accounts

    B2B apps are often simpler than B2C apps when it comes to data storage. In a B2B app, one account/user doesn’t need to know about another, whereas in a B2C app accounts/users have to have a global context for all other accounts/users (think Facebook Friend requests). Fully-contained accounts can be on individual databases or multi-tenant such that one or more accounts are on the same database delineated by an account ID.

    One analogy I like to use is housing for people. A fully-contained account on a private database is a like a single family home. Multiple fully-contained accounts on one database is like one building in an apartment complex where everyone gets their own space but there are greater economies of scale having everyone together.

    Challenges for fully-contained accounts in a multi-tenant environment arise when the size of the accounts start changing and growing at different rates. Back to the apartment complex example, one family wants a home gym and decides they want a new bedroom for it, only all the other three bedroom apartments in the complex are full. What does the family do? Well if the family can afford it the tendency is to go to a single family home that is suited uniquely to them.

    A single family home is much more expensive to maintain, on a per family basis, compared to a building in an apartment complex. Services like landscaping, security, and amenities like a gym or pool are much more affordable when spread out over dozens or hundreds of people. A single family home can have all those accoutrements but the cost structure is no where near the same.

    Specialized Sub-Systems

    Now, assume some accounts in the multi-tenant fully-contained database approach grow so large that they need their own dedicated database. With the housing analogy, larger families start moving to single family homes from the building in an apartment complex. Assume the apartment complex didn’t have a pool — the app didn’t have that feature yet. Now, the startup decides a new feature is needed — the equivalent of a pool — and adds it to the application. The pool is manageable in the apartment complex that houses 100 families with the cost of chemical treatments, cleaning, etc spread out over a large number of users. For the single family homes that were created by the accounts that got too large, each now has a pool by the nature of SaaS applications having a single code base for all customers, and those pools all need to be managed. Going from pool to pool, even with automated tools and help, becomes less efficient and more costly to do chemical treatments, cleaning, etc.

    Specialized storage and application sub-systems are designed to solve this problem. Think of a simple survey application. The info for the accounts, users, billing, survey questions, and more are pretty simple and not storage intensive. What is storage intensive is keeping track of all the survey responses and survey respondents. That information is going to grow exponentially compared to the core account data. It deserves a dedicated sub-system.

    Now, back to the housing analogy. Instead of families desiring a home gym moving to single family homes, the apartment complex introduces new buildings in the same complex, only the different buildings serve specific functions like a gym with an indoor pool, parking deck, and storage units for for each family. The individual features and storage needs get dedicated attention such that the regular gym with pool can grow into a 100,000 square foot facility with Olympic-size pool, and all the families can stay put in the apartment building that’s part of the same complex. Areas that change disproportionately can get the necessary attention without affecting other aspects of the application.

    Conclusion

    When starting out, fully-contained accounts is easier to implement and doesn’t require much overhead, making it the right choice for young B2B SaaS apps. If data grows linearly and everything is tightly related, keep it simple with fully-contained accounts. As the application grows, and certain types of data grow disproportionately faster than others, specialized sub-systems scale better and in a more cost-effective manner, making them the right choice for mature, data-intensive B2B SaaS apps.

    What else? What are your thoughts on these two schools of thought for scaling B2B SaaS app data?

  • Product Management Planning Process for a Startup

    Product management is one of the most strategic and critical components of startups. While the best products don’t always win, great products in a great market are almost always successful. Unfortunately, product management is still much more art than science, although actionable data is becoming more prevalent.

    Here’s an example product management planning process:

    • Create a simple Google Spreadsheet with sheets for different constituencies
    • Solicit requests from sales, marketing, services, support, client advocates, product management, and engineering in individual sheets
    • Review the customer idea exchange and take the top 10 most popular items and 20 other items that have the most bang-for-the-buck and add them to a new sheet
    • Analyze trends from the 100 most recent support tickets and confirm the big ones are in the Google Spreadsheet
    • Categorize every item based on priority (low, medium, high) and difficulty (low, medium, high)
    • Get a group of stakeholders together, no more than five people, and debate everything that’s been assembled and decide on the items for the next quarter
    • Share the quarterly roadmap with the team and create alignment
    • Repeat each quarter

    Product management planning and roadmaps should be fluid with 20% of the quarterly time allocation left open for new items that might arise. There’s no perfect product management planning session but with a thorough process, proper categorizing of issues based on Covey’s quad one and quad two, and hard work, the results will be invaluable.

    What else? What are your thoughts on this example product management planning process for a startup?

  • Covey’s Priorities Quadrant System for Startup Product Management

    Stephen Covey has a well-known quadrant system for priorities that is beneficial for product management in startups. Here’s how it works: there are four boxes based on not important & important up the left and urgent & not urgent across the top in order to prioritize what needs to be done. It looks like this:

    The startup urge is to work in Quadrant 1 – important and urgent. Yes, the important and urgent things need to be done but the mistake I commonly see is not enough time spent in Quadrant 2 – important and not urgent. Quad 2 is often infrastructure, big picture, or long-term items that have significant compounding effects. Whereas the general time allocation is likely 90/10 with 90% in quad 1 and 10% in quad 2, the more successful startups consciously do 80/20 with 80% in quad 1 and 20% in quad 2. The next time you look at potential product features, put them in quad 1 and quad 2 buckets and see how the time allocations stacks up.

    What else? What are your thoughts on using Covey’s priorities quadrant system for startup product management?

  • “They Thought of Everything” is Wrong for Web Startups

    Recently I heard an entrepreneur exclaim how much he liked a certain product by saying “they thought of everything.” That saying wouldn’t leave my mind until it hit me later in the day — the startup didn’t think of everything, rather, they collected ideas from customers, partners, employees, and competitors. The ideas were then filtered and (hopefully) a product team with an opinionated vision made a decision on what to include, and more importantly, what to exclude (most things).

    Entrepreneurs need to be vigilant about what does and doesn’t go into the product. Here are some things to think about when it comes to product management:

    • Most feature requests should receive a “no”
    • Don’t be all things to all people
    • Develop an opinionated vision and stick with it
    • Solicit input from all stakeholders and continually communicate with them

    The next time you hear the phrase “they thought of everything” you should think to yourself “they filtered the noise to build a product that’s great for me.”

    What else? What are your thoughts on product management and the phrase “they thought of everything?”

  • Measure Customer Engagement for SaaS Apps

    One of the many things Salesforce.com does well is generate a monthly customer engagement email that gets emailed to account administrators. In the email, there’s a separate line for each of the major functions of the application as well as how many times it was used by the account in the last month, or if it hasn’t been used yet. Salesforce.com has automated part of the account management process, but more importantly, helped customers get more value from the software.

    Software-as-a-Service (SaaS), since it’s delivered over the web, can have end-user interaction measured using standard web analytics tools like Google Analytics. Like with any application, it’s easy to measure which users use which features. SaaS providers should measure customer engagement in their app.

    Here are some potential customer engagement categories to measure:

    • Value generated by the application (e.g. return on investment)
    • Number of user logins, as well as logins by type of role
    • Modules used, frequency of usage, and importance of modules (e.g. the more important modules are weighted more heavily)
    • API calls, if applicable, which measure the activity of third-party integrations with the SaaS app

    SaaS providers should measure customer engagement for their apps and incorporate it into their processes.

    What else? What other customer engagement categories should be measured?

  • Twitter Bootstrap for Web App UIs

    In the past week two different entrepreneurs mentioned the Twitter Bootstrap for web application user interfaces. I had heard of it before but hadn’t looked into it yet. Wow, it’s impressive! The idea is that instead of reinventing the wheel, or even using simple libraries that have some UI components, why not provide a complete library for layouts, controls, colors, etc. Twitter Bootstrap is exactly that.

    Here are some benefits of the Twitter Bootstrap for web app UIs:

    • It provides a common platform with which others have already extended
    • Like open source software, the more people that use it and give back, the better it becomes
    • The user interface and user experience can easily take of 10-20% of the time for initial new product development, and can now be significantly cut down with Twitter Bootstrap
    • A consistent, modern UI makes the application more professional and trustworthy

    Startups building a web app from scratch should seriously consider using the Twitter Bootstrap.

    What else? What are your thoughts on Twitter Bootstrap for web app UIs?

  • Architecting an Infinitely Scalable B2B Web App

    An entrepreneur was recently telling me how he was worried that his B2B web app might not scale if things took off. Of course, I explained to him that that would be a high class problem to have and that he shouldn’t worry about it. Focusing on finding product/market fit and customer acquisition is much more important. With that said, I did describe a simple approach to architecting an infinitely scalable B2B web app:

    • Round robin DNS to a handful of load balancers in separate data centers
    • Databases with near real-time replication between data centers
    • Separate databases for global information (like users, accounts) and limitless shards to hold account-specific information (multiple accounts per shard, when a shard gets too large it is split into two shards)

    The benefit of most B2B web apps is that one account or user doesn’t need to know about another account, and thus the system can scale by adding more and more database shards horizontally with a global database that keeps tracks of what account is on what shard.

    What else? What are your thoughts on this approach to an infinitely scalable B2B web app?

  • Startups Should Provide Maximum Value with Minimum Customer Effort

    AMG Affalterbach DaimlerChrysler customer serv...
    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?

  • User Conferences and Startups

    Grand Canyon, Grandview Point
    Image by Laughing Squid via Flickr

    As we finished up our last minute preparations for next week’s user conference I’m reminded why they are such great events. One of the most important aspects of building a great startup is developing a passionate community of users and partners. Even with the advent of great technologies like email, screen sharing, message boards, blogs, and social media there’s an element of human connectedness that can only take place face-to-face. User conferences provide just that: the strongest level of community possible.

    When in the course of a startup, there comes a time where customers want to gather together, whether as a simple user group or as a large annual user conference, the startup should facilitate and embrace it. User conferences represent the largest and most complex user events, and also the best. User conferences, much like pep rallies before a football game in high school, are filled with tremendous energy and excitement as everyone comes together around a common cause.

    User conferences require significant time and effort but are worth every ounce of energy.

    What else? What are your thoughts on user conferences and startups?

  • The Startup Tendency is to Over-Engineer the Product

    Shepard Fairey Press Preview

    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?