Why, as project managers, do we think that what worked on our last project will work on our current one? If the definition of a project revolves around it being unique, why do we try to standardize our approach so much? Checklists, templates, a PMO mantra of “this is how you should do project management” isn’t necessarily well received, especially during the early stages of product development.

Think about it - we approach a project with a bunch of standardization, project management lingo, asking a bunch of questions and it is no wonder why, out of all the stages of product development, Conceive is where we find the role of the project manager the most underutilized. It’s as if our friends in product management want nothing to do with us. And because there is so much unknown during Conceive, we can quickly fall into the trap of thinking they’re right - there’s not a lot for us to do here - and be resigned to wait until requirements are further along.

Product Managers, on the other hand, can view themselves during Conceive as solely responsible for figuring out the answers. This perspective can put a lot of pressure on them. Having us project managers asking a lot of questions can be viewed by the product manager as us challenging their capabilities or performance. “So how are you going to go about figuring it out? What steps are you going to take? How long is it going to take you? Are you dependent on anyone or anything else for you to complete your tasks?” These are the typical questions we would probably start to ask - right?

In our mind completely harmless; in their minds, somewhat challenging. They can become defensive and respond with statements like “there’s lot going on here! Trying to figure this out isn’t necessarily a task by task process. Innovation isn’t something that can be put into MS Project. We are going to be involved with market research and customer surveys figuring out our strategy for where we are going to take this product. A lot is going to change and be in flux over the course of this stage. Managing a task by task schedule won’t make sense.”

So what do we do? How can we help, if no one is willing to talk to us? Perhaps it’s time to change our approach.

My background is in science. I was raised as a scientist long before I ever became a project manager. So, my perspective of the Conceive stage of product development is a bit different. To me, Conceive looks like this:

• Formulate hypothesis
• Test hypothesis
• Record data
• Evaluate hypothesis
• Repeat

Those of you scientists out there might find this approach resembling the Scientific Method. The scientific method refers to a body of techniques for investigating phenomena, acquiring new knowledge, or correcting and integrating previous knowledge. To be termed scientific, a method of inquiry must be based on gathering empirical and measurable evidence subject to specific principles of reasoning. The Oxford English Dictionary says that the scientific method is “a method or procedure consisting in systematic observation, measurement, and experiment, and the formulation, testing, and modification of hypotheses.” The chief characteristic which distinguishes a scientific method from other methods of acquiring knowledge is that scientists seek to let reality speak for itself, and contradict their theories when those theories are incorrect.

Doesn’t this sound a lot like the Conceive stage of product development? We, as a product team, are trying to understand a perceived problem for which there is no identified solution. Customers may be telling us one thing, but their behavior may be showing us another. Markets need to be explored and data must be collected to either confirm or deny assumptions. All of this data must be validated before any true business case for the product (or project) can be developed.

Below are four tips which I use with my product managers as I try to help them understand and plan their approach for Conceive:

1. Use your experience:
   consider the problem and try to make sense of it.
2. Form a conjecture:
   When nothing else is yet known, try to state the explanation, to someone else.
3. Deduce a prediction from the explanation.
   If you assume #2 is true, what consequences follow?
4. Test:
   Look for the opposite of each consequence in order to disprove #2. Is it a logical error to seek #3 directly as proof of #2.

This approach takes the technical project management speak out of the conversation and centers the conversation around the importance of what the product manager is trying to accomplish. You have to remember, most people, although familiar with the profession of project management, really don’t understand the language, nor should they have to. However, most people have had at least a biology class in their lives and using this scientific method approach puts the work in a language they can more easily understand.

Remember, your goal as a project manager during this early stage is to provide your team a foundation – a foundation built upon clear performance objectives and success criteria centered on targets and measurement. Using the scientific method gives you a collaborative approach to achieve this goal.

Stating and documenting clear performance targets are the prime means of project scope control and performance targets are a starting point for implementation of the scientific method.

This approach works. The way I look at things is if I can get the product manager and the team to a place where a Product Decision Matrix can be created, I can now have an informed data driven discussion about how we want to reach out goals. Let’s start by trying to understand what the goal really is behind the work.

In Conceive the endpoint is the product decision matrix. That’s where I want to get to. If I can get to a prioritized list where high level business and market requirements can be written (epics), then I can provide high level estimates. From high level estimates, I can start to plan what is possible in a release. What team skill sets are required in the release and what risks are associated with the release. Here is where I can actually start to put my project plan document together. If a designer or an architect needs a blue print... so do we!