How to Get Started Developing Your New Product

Advice from a Senior Product Development Executive

Leading the Product Realization Process

So, you just got assigned to lead a new project for your company.  Surely many thoughts are going through your head.  First, you have to know where to start.  Let’s assume management did not catch you by surprise, and that you have been involved in discussions about the new product you are to be involved in.  Let’s also assume that you are leading the initial charge in the product realization process.  So, what should to do first, you may ask?

The first thing you need to do is gather all the information around the product and organize your thoughts. Before you start to think of which resources you’ll need to get it done and how much funding the effort will require, take a moment and get a full understanding of the concept and product.

To understand the product and its application, you must run through a set of questions, and you need to understand the answers or at least realize that there are questions that have to be addressed early on.  Take a look at how the product addresses a need.  Understand its application and how it is going to be used – and by whom.  It would be a great time to understand all the use cases and every role that interfaces with the product during its lifespan.  I always try to think of the product as part of a system. In this way, I have a good feeling for how it works, who interacts with it, and in the end, how the product makes money for the company.  Now you can start to lay out the high-level requirements for the product that I discuss later.  But before I do, some other project execution questions need to be answered or at least understood.

Start pulling together a strategy.  Identify when the project starts and when it needs to be completed.  By ‘completed’ I mean that your goal at this point may be a prototype, a minimally viable product (MVP), or full-scale production.  Given the complexity of the product, there could also be months between these iterations with massive teams working full-time to get it done.

Next would be to understand the necessary budget to get this done. This can be challenging for several reasons.  For those of you who don’t do this every day, understanding the costs requires careful deliberation.  Please note, this task is difficult for everyone, so you are not alone. I think that costs are harder to understand than schedules even though they work in lockstep. I suggest this because you typically have more flexibility with managing a schedule by adding resources or performing tasks in parallel.  A rule of thumb is to realize that the longer a project is, the more it costs.  It is almost guaranteed. Time equals money.  Get a high-level understanding of the process, load in reasonable durations for development, and then assess how many resources must be assigned to the project to get the job done.  If you have not done this before, you may want to seek some assistance from someone in your company or externally from a firm. Before going outside your company to seek the support of a design firm, be sure you’re able to present the product plan in such a way that you offer the most useful information to that firm in a logical way.  If you are seeking help externally, be prepared to spend some money, and having precision around the details provides the best return on investment.

The best place to start is with an excellent presentation of what the product is and the problem it is going to solve for the end-users. If you do not have the resources internally to generate this presentation, you may need to hire a person or team and participate in a brainstorming event that allows you to walk away with a pitch deck that pulls all aspects of the product into a concise story.   If you already have a Marketing Requirements Document (MRD),  you would leverage it to brainstorm and sketch out ideas for the product and its surrounding ecosystem.  Also, as part of the exercise, you should assess all the uses cases, understand all the actors (users or systems that interact with the product) and stakeholders.

If run effectively, such a brainstorm session will enable you to start defining system/product requirements, which will then be captured in the form of a Product Requirements Document (PRD). The PRD is not fully developed during brainstorming – it requires an engineering team to flush out all the derived requirements.  These requirements translate into tasks for the team and provide a mature starting point for the subsequent efforts.  Remember, the PRD is a living document and continually managed through the development cycle.  A PRD is critical to developing a plan to which you can start assigning resources and budgets.

Now you can start building a project schedule.  There many lifecycle models out there, but let’s face it; you must develop a plan that is easy to understand and that can evolve.  You also need to make sure that you manage the plan.  If you are using a software tool to develop the project schedule, make sure you know the tool well before starting.  A common ‘go-to’ scheduling program like Microsoft Project has many capabilities and features, but using the tool to plan and manage every detail of the project effectively is a full-time effort.

Keep it simple, but well detailed and organized.