Category Archives: Product Mgmt

Don’t Do Several Independent Products in a Web Startup

1 Reply

After a product’s reached a modest level of traction, there’s an entrepreneurial tendency to start thinking of the next product to build — don’t do it. Too often I see startups with multiple products where the first one was a winner and the next two haven’t gone anywhere. Now, one web app segmented by functionality for different buyers is great and is not the same as separate code bases for truly independent applications.

Here are a few thought on multiple products within a startup:

  • Startups are inherently resource strapped, such that spreading people thinner reduces the effort on everything
  • Complexity grows exponentially as there’s more than expected overhead constantly figuring out how time will be allocated
  • When talented people are transferred from the cash cow product to the new product, they get pulled back to the main product as soon as things aren’t going well or a serious challenge is encountered
  • Sales and marketing systems, sites, etc become much more difficult to manage and execute well with multiple products

There are always exceptions to the rule, but entrepreneurs should avoid doing several independent products in a web startup.

What else? What are some thoughts on the challenges with having multiple products?

Internal Startup Product Jargon

Leave a reply

With any new product development comes debate about product jargon. Product jargon is the different terms and names used for features, modules, etc. With a clean slate, it’s easy to try and reinvent the wheel with new terminology and ways to describe things. Don’t do it.

Here are a few thoughts on internal startup jargon:

  • Use the industry standard terms for features and modules so that prospects and customers don’t have to relearn things
  • Use Google Trends and Google to find search volume of terms in order to decide what’s the most common phrase or name. Plus, this plays into search engine optimization (SEO).
  • Make sure that that internal code for the feature/module matches up with the marketing name for the feature/module (I’ve seen this many times where the two don’t align and it creates on-going headaches between different teams as well as new engineers that are learning the code base)

Internal startup product jargon is the norm and entrepreneurs would do well to ensure standardization across their product and their industry.

What else? What are your thoughts on internal startup product jargon?

SaaS Momentum is Strong

2 Replies

Recently I was talking with a friend about entrepreneurship and technology. The topic of Software-as-a-Service (SaaS) came up and how it’s been a hot area for years now. After discussing it further, we agreed that SaaS is just getting started and shows no signs of slowing down.

Here are some of the reasons SaaS is so disruptive:

  • Pace of innovation is much faster for a tech company compared to installed software due to delivering software over the web
  • Ease of on-boarding a new client and getting value is a magnitude better than the previous way
  • Removal or lack of IT involvement empowers line-of-business managers to be more autonomous and self-sufficient
  • Anytime, anywhere access changes the approach to work and frees up team members to be productive on their own schedule
  • Open APIs to share data and connect systems in an automated fashion is 10x more efficient than traditional enterprise software

Software-as-a-Service has another decade of rapid adoption ahead and is just getting started.

What else? What are some other reasons SaaS momentum is so strong?

Atlanta Tech Village for the Second Atlanta Location

3 Replies

One of the goals for the Atlanta Tech Village is to be a great spot for an Atlanta office for technology companies headquartered in other cities. Atlanta has such strong natural resources in software engineering/product management as well as sales and marketing that it’s the perfect spot for a remote office. There’s another need in the market that I didn’t anticipate: technology companies headquartered in Atlanta that want a second Atlanta location to do new product development.

Much like Steve Jobs, when inventing the Mac, put his team in a separate building down the road from Apple headquarters (with a pirate flag on top!), there’s a desire for engineering and innovation of new products to take place in an environment that isn’t encumbered by the traditional way of thinking and current product offering. Tech companies, especially small-to-medium sized companies, struggle building new products, which is one of the reasons why startups continue to be successful. Absent acquiring a startup, one of the best ways to launch a new product is to put a team on it in a different physical location.

Atlanta Tech Village is a great spot for that second Atlanta location to do innovation with an amazing community and without all the overhead of a traditional office.

What else? What are your thoughts on having a second location in the same city as headquarters to work on a new product?

The Art of the Customer Discovery Interview

4 Replies

Customer discovery is hard. As an entrepreneur with a bias towards action, the action of building features in a product is much more fun than talking to potential customers. Only, if you don’t talk to potential customers early and often, the chance of success is significantly diminished. Once you’ve mentally agreed that talking to potential customers before or during the earliest stages of product development is key, it’s time to do customer discover interviews.

Here are a few things to keep in mind with customer discovery interviews:

  • Don’t lead the witness — it’s all too common to try and guide the potential customer down a path the jives with your desires
  • Ask broad, open ended questions
  • Get a good understanding of how things work currently with as much excruciating detail as you can uncover
  • Find out what the ideal solution would be if time and money were no issue (if you could wave a magic wand and have anything you wanted , what would it be?)
  • Never show any prototypes you might have until after you’ve asked all your main questions (don’t introduce bias!)

Customer discovery interviews are super valuable and should be employed by all entrepreneurs.

What else? What are some other ideas on the art of the customer discovery interview?

Ask for Product Feedback from Prospective Customers, Not Friendlies

2 Replies

Recently an entrepreneur reached out to me asking for feedback on his Software-as-a-Service (SaaS) application. By feedback, he was interested in my actual thoughts on the user interface, user experience, and overall application. Unfortunately, I’m not his target audience, and while I can give ideas from a general web-app snob/enthusiast perspective, what I think doesn’t matter — what matters is what prospective customers think.

Here are a few reasons why it doesn’t make sense to ask for product feedback from friendlies:

  • Customers pay the bills, not people who like you and want you to succeed
  • Feedback from non-prospects can influence thinking in a way that doesn’t add value
  • Time is best spent with actual prospects
  • More functionality built into the product now that the market doesn’t need significantly slows down future development

The next time an entrepreneur asks for product feedback from you, and you aren’t the target audience, respectfully decline and redirect the energy to customer development.

What else? What are your thoughts on asking for product feedback from prospective customers, not friendlies?

Go Deep Instead of Wide with a SaaS Product

2 Replies

Recently I was talking with an entrepreneur that was showing me his Software-as-a-Service (SaaS) product. After a quick 10 minute demo, which was crisp and complete, he started talking about what’s next and how they were moving into an adjacent opportunity. I proceeded to ask about adoption rates, what were the “must have” features of the product, and what would the benefits be if they continued to go deeper instead of wider. The core product looked good and I didn’t buy the strategy to go broader.

Here are some reasons for going deep with a SaaS product:

  • Be the best that you can be instead of just OK on a number of fronts
  • Resources are limited, so use them wisely
  • Deep functionality to provide specific value is much more defensible than light-weight functionality
  • Specialists command much more money than generalists
  • SaaS is readily integrated with third-party products via APIs such that the idea of an all-in-one suite is not going to win in the future

Whenever debating product functionality, always ask yourself if you’re going deeper or wider, and the vast majority of time the answer should be deeper.

What else? What are your thoughts on going deep instead of wide with a SaaS product?

Rolling out Roadmaps in a Startup

1 Reply

One of the more delicate, and demanding, documents in a startup is the product roadmap. After getting feedback followed by buy-in from the different constituents, it becomes time to rollout the roadmap to customers, team members, analysts, and prospects (some pre-sale engagements sell the vision of what’s to come in the product).

Here are some ideas for rolling out a roadmap:

  • An annual formal presentation on what to expect over the next 12 months at the user’s conference
  • A quarterly customer advisory council that meets via GoToMeeting and gets a private walk through as well as Q&A of the roadmap
  • A quarterly webinar for existing customers combined with a blog post summarizing what can be expected in the next three months
  • A monthly employee-only product show-and-tell that gives a preview of progress for each item on the roadmap

So much time goes into building and managing the product roadmap that often there isn’t enough effort put in to rolling it out to constituents. Communicating the vision is a critical part of successful startups and should not be underestimated.

What else? What are some other ideas around rolling out roadmaps in a startup?

Minimize Technical Complexity in a Pre-Revenue Startup

1 Reply

Early on in a startup, especially a pre-revenue one, it’s super easy to add technical complexity to the product since there’s a clean slate. With no existing users and no lock-in, there’s nothing slowing the engineering team down from incorporating a variety of programming languages, best-of-breed open source components, and more. My advice: minimize technical complexity and moving parts as much as possible, even while sacrificing elegance to solve challenging problems.

Here are a few reasons to minimize technical complexity in a pre-revenue startup:

  • With a limited engineering team it’s important to keep things simple so that everyone on the team can substitute for anyone else (once the team grows having more specialization works well)
  • Complexity is much harder to take out than add in, so start simple, even if it isn’t elegant
  • Getting something working that customers love is much more important in the early days than having the most scalable back-end
  • More moving parts and different types of systems create more complexity for sys admin work, especially upgrades and on-going maintenance

Some technical complexity is unavoidable, but whenever possible, it should be minimized. Keep things simple, move fast, and stay close to the customer.

What else? What are your thoughts on minimizing technical complexity in a pre-revenue startup?

Continuous Deployment in Startups

2 Replies

Continuous deployment is a methodology whereby software code checked into a repository for a web application is automatically sent to the production server after all automated tests pass with no other human intervention. While not being an easy process to describe, it’s revolutionary in how it affects software development. The traditional software development process, even if agile, often involves bottlenecks around manual QA, a limited number of engineers empowered to push a release, and numerous issues when major changes are pushed.

Here are some thoughts on continuous deployment:

  • Software releases go from big productions to non issues
  • Small changes result in small issues and large changes result in large issues (bugs are inevitable, so keep them small)
  • Automated testing becomes a critical part of the development process and no longer an after thought (there’s no right answer to how much code coverage is necessary other than it needs to be suitable to the product)
  • New developers should push code to production on their first day, setting the tone for a culture that moves quickly and isn’t afraid to make mistakes
  • Config flags are an important part of continuous deployment such that code that’s being worked on, but not ready to be seen by end users, is still pushed to production during development

Software-as-a-Service, whereby programs are delivered over the internet, makes continuous deployment possible (continuous deployment doesn’t work for installed software). With time, continuous deployment will become more prominent, especially when firms like Etsy espouse its benefits.

What else? What are your thoughts on continuous deployment in startups?