Why 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 standardized, project management lingo, asking a bunch of questions and it’s no wonder that, 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 waiting until requirements are further along.
Product managers, on the other hand, often view themselves as solely responsible for figuring out all the answers during Conceive. This perspective can lead to a lot of unnecessary pressure.
Having project managers asking a lot of questions can be viewed by the product manager as challenging their capabilities, authority, or performance. We, project managers, often have a long list of questions. “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 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. Product managers can become defensive and respond with statements like “there’s lots going on here!” Trying to figure early stage product development activities out isn’t necessarily a task by task process. Innovation isn’t something that can simply be put into MS Project. We’re going to be involved with market research and customer surveys figuring out our strategy for where we’re taking 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.
Here are four tips that I use with product managers as I try to help them understand and plan their approach to Conceive:
- Use your experience: consider the problem and try to make sense of it.
- Form a conjecture: When nothing else is yet known, try to state the explanation, to someone else.
- Deduce a prediction from the explanation. If you assume #2 is true, what consequences follow?
- 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 jargon 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.
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.