Category Archives: Product Mgmt

SaaS Apps Can Learn from Casual Game Engagement Techniques

Leave a reply

One of the more common techniques to increase engagement and usage of casual games on the iPad is to provide goals or challenges each time the game is played. As an example, the three active goals in a game might be to beat your previous high score, get to level five, and purchase a digital item in the store. Some, like beating your high score, are context-sensitive and straightforward. Others, like purchasing a digital item in the store, are designed to increase the user’s engagement with different parts of the game, and set the foundation for in-app purchases.

Software-as-a-Service (SaaS) apps should learn from this approach. In SaaS apps, it’s easy to automatically track what features are, and are not, being currently used. With this information, as well as analytics around what’s going on with usage of active features, the software could recommend new features to take advantage of as well as ways to get more value from existing features. Even better, data across multiple customers of the SaaS app can be anonymized and used for benchmarking, so that the recommendations give a context as well (e.g. you’re 5% below the average for this category and here’s what you should do to improve).

Here are some example goals or challenges that a SaaS app might provide:

  • Create a new page called ‘about’ in WordPress
  • It takes you an average of 40 days to get paid, and for your type of business the average should be 35 days, according the QuickBooks app, so here is a best practices guide to improving payment turnaround
  • Try out our new commenting feature in a cell in one of your Google Spreadsheets

The next time you’re contemplating ways to increase engagement and reduce customer churn, consider goals and challenges on the main application screen of the SaaS app.

What else? What are some other things SaaS apps can learn from casual game engagement techniques?

Startups Need to Get Out of the Building

1 Reply

Today was the kick-off for the second cohort of startups at Flashpoint, an accelerator at Georgia Tech. The day started with introductions between the new startups and their mentors, followed by a primer on startup engineering/lean startup methodology, and concluded the morning with each team introducing themselves and their business, with a business model canvas in the background.

The afternoon assignment was to get out of the building and talk to potential customers. Here are some thoughts on startups getting out of the building:

  • Steve Blank says, “In a startup, no facts exist inside the building, only opinions”
  • Resist the tendency to talk to friends that are potential customers as your only source since their feedback is going to be tainted by their relationship with you
  • Go to where you customers are most likely to be (e.g. at a specific office complex), not just where you might get lucky to find them (e.g. Starbucks)
  • Keep the questions open-ended by avoiding yes/no questions
  • Stay focused on finding answers to your hypotheses (it’s easy to get distracted)

Startups need to get out of the building and talk to potential customers right away. Too often entrepreneurs build their products in a vacuum and talk to customers after spending significant resources, and many times don’t have enough resources left to achieve success. Making the most of time and resources requires getting out of the building.

What else? What are your thoughts on startups getting out of the building?

Handle Initial Partnership Requests Via Email

1 Reply

Before startups say no to 99% of partnership opportunities you have to qualify and find out what it is the other company is actually looking to do. There’s a standard song and dance where a VP or co-founder from another company gets an intro through a mutual connection or sends a cold email asking to set up a phone call to talk about an integration/partnership/relationship.

Too often, myself included, if it looks interesting and targeted, entrepreneurs jump on the phone and spend an hour finding what the proposal actually is and what an integration might look like. Don’t. When the quality request comes in simply reply back via email and ask these three questions:

  • What, specifically, is the proposed integration?
  • What 10 customers have asked for this integration and why?
  • What parts can you do via the standard API we already have and what parts do we need that are non-standard?

These three questions will provide a wealth of information and save you a ton of time. Now, you still might jump on a call for 30 minutes after you get the answers but the quality of the call will be significantly better, saving everyone time.

What else? What other questions do you like to ask when handling initial partnership requests via email?

Gathering User Feedback For An Established Product

Leave a reply

User feedback is critical for building a successful software product. As the product matures and becomes established, user feedback is easier to get, but can also become overwhelming with requests from so many different constituents. Here are some ideas for gathering user feedback for an established product:

  • Quarterly check-in calls by a client advocate or account manager to find out how things are going
  • Idea exchange with single sign-on so that customers can post ideas and vote on other ideas
  • In-app net promoter score where you ask once per quarter how likely they are to recommend the product
  • Regional user groups with a company team member facilitating
  • Annual users conference with significant customer interaction
  • Customer advisory board that does a quarterly conference call with the VP of Product Management

Gathering user feedback with these methods is the easy part. The real challenge is organizing the information and combining it with your own vision and opinion for the product. Then, clearly communicating the direction and future functionality with the key stakeholders.

What else? What are some other ways to gather user feedback for an established product?

Platform-as-a-Service Options like Heroku for Startups

3 Replies

Aarjav asked about Platform-as-a-Service (PaaS) options like Heroku in the comments of yesterday’s post Cloud vs Colocation vs Managed Hosting for Startups. PaaS is great in that it offers the benefits of cloud computing with easy scaling up and down while encapsulating many of the more tedious system administration functions present when doing it yourself.

Heroku, owned by Salesforce.com, is one of the best known PaaS providers, especially in the Ruby community (they support other technologies as well but Ruby is still the most prominent for them). As an example, if you write a new Ruby on Rails application, to run that application you have to set up an environment and maintain it. Manual setup might take an hour if you know what you’re doing or 5 – 10 hours if it’s your first time. With Heroku, you can get things running in 5 minutes in a super simple fashion and as you scale or need more horsepower the process of resizing an instance or adding more instances is much simpler than a traditional cloud or dedicated server model.

Heroku runs on top of Amazon Web Services (AWS), so it is even more expensive than AWS EC2 instances, which are much more expensive than managed hosting which is more expensive than colocation. Out of the box, Heroku is great and fits in with my recommendation for startups to start with the cloud. Heroku does do things like kill web requests that take longer than 30 seconds, which forces code changes like using more background jobs, which is the right way to go but might cause more code refactoring sooner than desired.

Startups using a language like Ruby and a framework like Rails are well suited to start with Heroku and graduate from there as their success permits. Startups using a language like PHP have PaaS options like PHPFog to use as well to cut down on administration time and focus on building a business. Long term, PaaS falls under specialized cloud solutions and so the same thoughts around constant availability vs burstable needs, etc still hold true.

What else? What are some other considerations for Platform-as-a-Service options for startups?

Product Features that Don’t Fit

1 Reply

Last week I was working in a web-based product and I came across a feature that didn’t fit. By didn’t fit I mean that it felt out of place and there’s no way it’s potentially usable by 80% of the users. I’d be amazed if more than 1% of the customers have ever used it — it’s that out of place.

How did the feature get in the product? Here are a few guesses:

  • It was such an easy feature that it got in the product and out the door before it occurred to product management that is wasn’t a good idea
  • A client had a problem and this was support’s idea to help that one client (even though it wasn’t applicable to other clients)
  • Someone with a strong personality (a sales rep?) convinced others that it was a good idea to help close a new customer

Much like a supertaster who picks up on disproportionate flavors in food, strong product managers quickly reject features that don’t fit. Do you have features in your product that don’t fit?

What else? What are some other reasons features that don’t fit get into products?

Two Schools of Thought on Scaling B2B SaaS App Data

2 Replies

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

1 Reply

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

1 Reply

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

2 Replies

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?”