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

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

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?