A Tech Entrepreneur’s Guide to Early Product Development

Customer driven product development

Successful companies build products for their customers, not for themselves. An IT startup that doesn’t bring customers into the product development process early and often is making a strategic, likely fatal, mistake.

Customer validation always comes first—then comes technology and prototyping with talented engineers. Here is a high-level guide to introduce entrepreneurs to a customer-driven approach and the vocabulary to improve a startup’s chances of creating products that customers buy and use.

Early Product Callout

Key Roles: Product Owner and Product Manager – A Compass and a Map

In every product development process, there are two distinct roles: Product owner and product manager. The product owner is the client advocate. The product manager is responsible for the solution architecture and product support. The unique challenge with a startup is that many times the CEO wears both hats.

The Role of the Product Owner – Setting the Compass

The product owner is like a compass; without a compass, travelers (and entrepreneurs) get lost. The product owner performs the compass role by building a business model based on customer validation through which customers’ needs are met.


The Role of the Product Manager – Creating the Map

The product manager uses the results of the prototype to create a map that describes potential solutions and products—the various ways the startup can progress in the direction set by the customers and communicated by the product owner.


The Product Development Process – Keep Your Eye on the Compass; Improve the Map

Whether a startup insources or outsources product development, the entrepreneur owns the process and the outcomes.

A well-defined, repeatable process that includes the roles and activities by which the company designs and builds a product prepares an IT startup to create solutions that customers want to buy. As your startup iterates and the process becomes better defined to the particulars of your company, you are building a foundation for ongoing best practices that are a requirement for any organization that aims to scale.

Here’s a high-level approach that you can use to build a product development process that works for your customers and your company. The product owner and product manager work the process together, ensuring open communication between them as the process moves forward. The process starts with a hypothesis and creates user-driven information that a product development team can use to drive an Agile development process.

  • Hypothesis: The product owner and product manager start out in the same place—collaborating on a hypothesis about the target users and the envisioned solution. The hypothesis is based upon limited evidence and many assumptions. It is a tool to answer these questions: “What do we believe, and how will we prove or disprove it?” The right hypothesis is the compass that keeps the startup’s orientation aimed at serving its clients’ needs.
  • User Focus: The goal is to understand and learn from users. The product owner gathers potential users of the product. This is a great opportunity to reach out to users who are in companies that you view as prospects. Exercise your networking skills with local business people, industry contacts, or university or professional organizations; you may compensate them or not. Somehow you want to keep them connected as a group. However, within that group, consider each person as an individual. What are their pains and their desires—pains that your solution might alleviate or desires and goals that your product might help them achieve. Ask questions and listen. All your product decisions should be driven by a user focus and validated with customers/users.

Create a persona for each user that participates in the validation process. A persona is the top layer of understanding of an individual user. Demographics? Job responsibilities? Motivators? Frustrations? Goals? You will use these same personas to build out your sales process and funnel. An in-depth understanding of how buying decisions are made comes from understanding the situational attitudes that each persona has towards a product or buying action.

After you’ve determined each persona’s pain and desires, figure out their friction of change. What do we mean by the friction of change? What are the roadblocks to change for each persona? The hard truth is, that for some users, your product may solve every problem a user has and meet every goal, but, if the friction created by change is too severe, that can make it too difficult for a user to take steps to bring in your solution. If this is the case, better find that out now.

  • Prototype: Prototyping is a way to demonstrate the product to a potential user to get their feedback. Everything the startup learns while validating the hypothesis informs the building of the prototype. Prototyping takes on many different forms and paths to completion. Hardware prototypes use off-the-shelf parts; for software prototypes, wireframes are useful. Wireframes, screen blueprints that are a visual guide that represents the skeletal framework of an application. The goal is to get in front of customers, analyze their responses and iterate. That’s the basis for a customer-driven feature set.
  • Job Stories: Job stories connect the wireframes and personas. A job story is a powerful way to facilitate team conversation and discovery during product design. Job stories give the design process the context in which a real user will use the solution being designed to perform his or her actual job.
  • User Stories: A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want from the product and why. A user story helps create a simplified description of a product requirement which leads to the features that get built into the product.
  • Epic and Features: An epic is a way to define a large part of the product that can then be broken down into smaller pieces. A feature captures what the user wants to do. An epic is essentially a large part of the product that can be broken down. It’s important to recognize that an epic can span more than one project and more than one version. Inside an epic are features, which capture what a user requires from the product. A feature cluster is a collection of like features that all belong to a single epic.

Epic and features mapping provide the input that a product manager and development team need to create a minimally viable product (MVP) using Agile design. The goal of the MVP is to solve the target users’ problem in the simplest, fastest, most elegant manner possible. The MVP will evolve based on how the users use it.

Every step in this approach to product development, whether in planning, prototype, or programming, is tied back to the customer needs and desires.


This overview is written to give entrepreneurs a sense of how to consider and set up effective product development in a startup IT company.

  • Customer validation comes first and drives the process from beginning to end.
  • Prototypes and minimally viable products (MVP) help users talk about the features they want and will buy.
  • Whether development is in-house or outsourced, the startup owns the result.

This discussion is based on the Product Development segment of Rev1 Venture’s Startup Studio curriculum. Does your startup qualify for Startup Studio is a fit for your startup? Contact us here.

About Christopher Slee

Christopher Slee is the founder, principal, and chief product officer at AWH, a Dublin, OH software engineering firm currently celebrating its twenty-second year of creating great digital products for business clients. As Chief Product Officer, Chris is responsible for monitoring market trends, technology requirements, and opportunities. With this insight, Chris establishes strong hypotheses and a proven process to bring products to fruition successfully. Chris has the expertise to define the “how” for product development. He provides AWH clients with a capable development team and interacts with them to make a product roadmap a reality. Whether it’s developing a new product or expanding an existing one, Chris focuses on brand requirements and standards to help clients launch products that align with their vision and goals. Chris attended and now is an adjunct professor at The Ohio State University.