Category: Product Mgmt

Entrepreneurs love building products. An idea comes to mind to solve a big problem and it’s off to the races to get it developed and in the hands of potential customers. Only, the hard reality sets in once prospects see it. There are actually three challenges that must be overcome: people, process, and technology.

• People – As much as we like to think companies are rational actors doing their best to maximize profits, the reality is that humans make the decisions and aren’t nearly as rational as we like to believe. With people, there’s a tremendous amount of subjectivity and it’s difficult to get them to act.
• Process – Even if the people are bought in, there’s almost always a process change that’s required for one or more employees in the company once they’ve bought the product. People are creatures of habit and changing the way they do things is hard. Many entrepreneurs underestimate the importance of change management and getting a new process implemented.
• Technology – Building a simple, standalone application is easier than it’s ever been. Technology challenges really start to emerge when having to integrate with a number of disparate systems, supporting a variety of mobile devices (especially Android), and providing a great experience for all end-user skill levels. The technology is never done.

The next time an entrepreneur makes it sound like a new venture is going to be easy, ask the hard questions, especially around people, process, and technology.

What else? What are some more thoughts on people, process, and technology for new products?

We already know that the product manager is one of the most difficult positions to fill in a startup. Often, one of the co-founders or the CEO acts as the product manager until the startup is large enough to warrant a dedicated person (or there’s an opportunistic hire). Regardless of having a full-time product manager, there’s a continuous product management process. Here’s what the process looks like for many startups:

• Daily – Customer feedback via a GetSatisfaction-powered idea exchange, team member feedback in a product planning spreadsheet, and new features as well as bugs in the issue tracker (e.g. JIRA, Pivotal Tracker, or GitHub Issues)
• Weekly – Direct customer and prospect conversations, update key stakeholders, look for trends, document new functionality, and start/review the sprint (assuming two week product sprints)
• Monthly – Review the roadmap, evaluate the product metrics/KPIs, demo upcoming features to the team, and one-on-one meetings with stakeholders (sales, marketing, services, support, and engineering)
• Quarterly – Update the roadmap, call/web meeting with the customer advisory council, and revise components of the Simplified One Page Strategic Plan

Now, this doesn’t include aspects like sales demos, evangelism, strategy, positioning, and more that is often associated with product management. Rather, this is continuous product management process that is a core part of a successful startup.

What else? What are some more components of the continuous product management process?

For years, whenever an entrepreneur asked my thoughts on outsourcing core product software engineering, my response was that I haven’t seen it work. There were too many disconnects between the startup team and the software engineering team – nuances around the actual product goals – resulting in a poor user experience and frustration during iteration while being enervating for the entrepreneur. Now, while building products in-house is most common, more startups are finding success with some or all of the core product being outsourced, especially to get started (I still think in-house software engineering is a must once the startup has traction).

Here are a few thoughts on the rise of outsourcing core product software engineering:

• Open source provides more reusable components, both for the frontend (e.g. Bootstrap) and backend (e.g. Rails)
• General collaboration tools are stronger and more widely used (e.g. Slack, Basecamp, etc.)
• Product management-specific collaboration tools are stronger (e.g. Balsamiq, Aha, etc.)
• Certain software development firms have come to specialize in building products, as opposed to most that do one-off consulting projects
• Non-technical entrepreneurs are more technical, on average, due to the more pervasive use of technology, and thus are better at communicating product needs

When entrepreneurs ask me about building their product in-house, or outsourcing it, I still recommend building it internally, but outsourcing it is much more viable, and thus deserves some attention.

What else? What are some more thoughts on outsourcing core product software engineering?

Steve Blank and Eric Ries helped popularize the concept of the minimum viable product (MVP) as a way to get a functional prototype into the hands of potential customers as quickly as possible. Previously, too many entrepreneurs built complex, elaborate products without incorporating customer feedback, resulting in failure.

Now, with some of the latest JavaScript frameworks, the minimum viable product is even simpler: a front-end only MVP. Here’s how it might work:

• Use AngularJS, Backbone.js, or EmberJS as the JavaScript framework
• Grab Bootstrap for the UI
• Store data in the framework’s model (e.g. Ember Data)
• Write tests (e.g. Karma)
• Profit!

Really, the key difference with traditional web-app MVPs is putting more logic and data storage on the client side (the browser). Functionally, to the end-user, it feels and operates like a fully-functional application, only long-term persistence and back-end processing isn’t present. Much like Parse provides a flexible backend with little work for mobile apps, these modern, MVC-based JavaScript frameworks make for a front-end only minimum viable product.

The next time the minimum viable product topic comes up, consider a front-end only MVP as a simpler starting point.

What else? What are some more thoughts on a front-end only minimum viable product?

Back when we started Pardot in 2007, we didn’t know any better and decided that our product needed a separate name from our company. After tons of brainstorming we finally arrived at a name that we liked and was available: Prospect Insight. Since Pardot didn’t mean anything to anyone, we felt that our product name needed to be more descriptive, hence the name. Also, being a little nerdy, we liked that Prospect Insight could be abbreviated PI, hence lots of jokes about pi (3.14159…).

After several years of trying to build brand equity in both the company Pardot and the product Prospect Insight, all our customers would call up and ask for help with Pardot, not Prospect Insight. Customers didn’t care what we called the product as everything was simply Pardot. Instead of trying to fight it, we embraced it and rebranded our product as Pardot. That is, the company and the product were one and the same. To this day, you can go to prospectinsight.com as well as pi.pardot.com and see remnants of a disconnected product name and company name.

For startups, the product and company name should be one and the same.

What else? What are some more thoughts on keeping the company and product name consistent?

Product roadmaps are a tricky thing in startups. As a startup, one of the most important aspects of the business is the ability to move fast and make decisions quickly based on new information. With a detailed roadmap, especially one shared with key customers, the ability to change direction can be greatly diminished.

Here are a few thoughts on product roadmaps:

• Consider outlining the public-facing plans in minimal detail for flexibility
• Maintain an internal-only roadmap with more information and specifics
• Incorporate feedback from sales, marketing, services, support, engineering, customers, and partners
• Capture internal ideas in a simple Google Sheet with separate tabs for each constituency
• Provide an idea exchange for customers to submit requests (e.g. tools like GetSatisfaction)
• Constantly revisit the roadmap and question how the pieces fit together

Product roadmaps are an important part of any tech company. In startups, roadmaps are especially sensitive and should be dynamic whenever possible.

What else? What are some more thoughts on product roadmaps in a startup?

When entrepreneurs set out to build their company, they have grand visions and aspirations. The product needs to do this, and that, and the other thing. The list goes on and on. Only, product-market fit starts small. Really small.

Here are some thoughts on initial product-market fit:

• 10 friendly customers like the product and give friendly-focused feedback, helping move a bit closer to product-market fit
• 10 paying unaffiliated (non-friendly) customers sorta-like the product and give tons of feedback, significantly moving towards product-market fit
• 10 more paying unaffiliated (non-friendly) customers really-like the product and give great feedback, inching the product closer to product-market fit
• Finally, 10 more paying unaffiliated (non-friendly) customers rave about the product and have improvement ideas, but ones that are approaching the nice-to-have category, helping assert the arrival of initial product-market fit

Product-market fit is a continuum, and doesn’t happen quickly, but when it does happen, the types of customer responses change, and enthusiasm grows. Look for happy customers, with minimal issues, and less-critical improvement suggestions, and there’s a good chance product-market fit has arrived.

What else? What are some more thoughts on initial product-market fit?