PM-ing the Fuzzy-Front-End of Product Development

I’m going to begin this professional commentary on project management by telling you a story from my youth. So far back in my youth, in fact, I don’t even remember it firsthand. But it’s been relayed to me from a couple of different perspectives.

I grew up in an A-frame home in a rural, wooded neighborhood. Directly off our backyard was a steep hill that led down to a lake. It was a blessing to grow up here, but a real pain to clear the grass/weeds on our massive, cliff-like hill. At the time this story takes place, I was around three-years old. This meant it was my dad’s responsibility to manicure the mountain, er I mean hill.

One day, I was watching my dad work away in the heat of the summer, swinging a manual weed cutter to level the foliage. As he took a hard swing with the implement, he slipped just enough to change its trajectory. It landed directly on his shin. Seeing my father’s Irish temper take over and a lot of words I didn’t understand start to spew out, I decided it was probably time to go inside.

Indoors, I went upstairs to find my mom in her bedroom watching TV. I climbed up onto the bed, leaned back against the pillows, crossed my legs, folded my hands behind my head, and very calmy said, “G#%@$&! it, Mom, how are you doing?”

Why recite this story in a blog post about how to project manage the fuzzy-front-end of product development? Because much like an unfortunate day of weed cutting, you might start out in the fuzzy-front-end intending to clean things up. Then, before you know it, your toddler is cussing at his mother. That in mind, let’s talk about a few pointers that might help you wrangle the chaos:

4 Tips to PM-ing the Fuzzy-Front-End of Product Development

#1 – Understand Your Aim

There have been times in advanced product development when I’ve been asked, “How does this work differ from product development?” There are a few ways to answer that question. One key differentiator is how many knowns you might be working with.

A large tenet in project management is proper scoping of a project. The scope might be developed by asking questions like: What are we trying to accomplish? What deliverables are there? What are the product requirements? What is the timeline? How many resources are needed to complete this work?

On the fuzzy-front-end, it’s not a given that you can answer these questions on day one. In fact, many startups or companies launching a new product in their portfolio shouldn’t be working to a scope at the outset.

What they should be doing is working as efficiently as possible to learn enough so a healthy scope can be built.

It’s the difference between saying, “Okay, here are the rules to this game.” And saying, “We have some pieces, a board, and a week to decide the set of rules that would make the best game… GO!”

If you’re a project manager, you might be thinking that working without a scope gets you off the hook! That is not the case. Your work pivots to moving as many items as possible from “this product could” or “should” to “this product will”.

You might use several tools to identify those targets. Ultimately, you’ll want to focus your efforts on the most efficient path to learn about the riskiest features of your product.

#2 – Know When Good is Good Enough

This is a tough subject. There are legitimate reasons to consider investing more time on the front-end of product development. By a percentage of cost, product design certainly casts the largest shadow on the lifecycle of a product. The upfront design needs to be right, as making design changes further down the development cycle will typically cost you even more.

As a PM on the fuzzy-front-end, there’s an art to helping teams know when to move to the next phase of development.

I’m convinced that in some personality assessment somewhere there should be a persona called, “The Eternal Conceptor”. I believe their ancestors were philosophers. If they could only work outside these pesky social constructs, they’d be fully self-actualized sitting in the “sandbox” endlessly exploring their curiosities.

While I’ve met some brilliant people in this category, and truly enjoy watching them diverge and wander and sprinkle their concepts with intriguing elements of past explorations, it’s the project manager’s job to help them identify the green lights to know when it’s time to move.

In the common scenario where scope is still being built through learnings, I find it usually serves the team well to define a timeline to explore concepts.

This could land in a number of places: a solid decision based on the exploration, a mutual decision to continue the exploration based on more unknowns coming to light, or a decision to pivot based on roadblocks or failed hypotheses.

No matter the findings, timeboxing your efforts allows you the best chance of exploring, learning, and ultimately deciding what your product WILL do. Each iteration allows you to ask deeper questions than the iteration before.

#3 – Understand the Gaps on the Team

At the front end of development, you likely want to consider a wide range of inputs. The skills required to consider, gather, assemble, and analyze these inputs are more diverse than what might be needed further down the development cycle as requirements and process get more defined.

Determine the key activities and requisite skills required as early in the project as reasonably possible, and revisit that plan periodically throughout the development cycle.

For instance, you may want to consider primary and secondary market research. You might spend time creating personas and empathizing with the user experience. You could benchmark competitive or cross-industry designs, ideate on solutions to product problems, analyze business cases, determine product and market fit, build a minimum viable product, conduct user testing, define decision criteria, create launch strategies, and the list goes on and on and on.

While you might not need to execute in all these areas for a specific product design, it’s likely that there are valuable inputs in this early phase that you might not feel comfortable to create, explore, or execute. Even if your company has competency in all these spaces, we see time and time again how coordinating cross-functional teams in an agile manner can create challenges. I’d encourage teams to make sure the right perspectives are represented early on. If you’re missing skillsets or inputs—find ways to get them.

#4 – Be Ready for the Unexpected Answer

Most people like to turn around and look backwards in retrospect from time to time. It might be browsing old family photos, seeing your old Facebook status (who was that person, right?!), or maybe learning about some of your ancestry. In the world of project management, that turns into a retro on how projects played out, or in program management it might look like a retro on why one product is carried forward and others are left behind.

It’s always so interesting to see how key decisions were made along the early timeline in product development. Why was this product concept selected? Why were others left behind? Who did you use to test your early assumptions, or how did you go about testing?

There are many methods to executing this work, but there are always assumptions baked in if you dig deep enough into the methodology. Knowing this, it might be easy to hold your ideas/concepts/product designs close to the vest, but that is a mistake.

Psychologically, it’s important to hold these concepts in the right place. These ideas might feel like your children. But just like in parenting, we need to let these ideas mature. They will change, they need to. I’ve seen scenarios where project teams move forward with what was at one time the nineth- or tenth-ranked concept.

Market research might inform you that the need a product fills is not as broad as you thought.

User testing might show you that your product concept is not as intuitive as you thought.

Prototype testing might indicate the mix of technologies you brought together isn’t as robust as other solution sets.

The key is this: Don’t be committed to a good idea regardless of how good the signals are along the way. Be committed to finding good information and let that make your good idea turn into a great one.

There are more considerations to PM-ing the fuzzy-front-end of product development. But this list speaks to some things I’ve seen trip teams up most often.

If you find yourself in this space, don’t hesitate to reach out. I’m always energized by digging in and understanding what the journey might look like to innovate and create something new. Even if this chapter of your story includes some frustrations and perhaps a few cuss words—I’ll listen. I learned those words long ago!

Let us know how we can partner with you with the fuzzy-front-end of product development. Customers value our cross-functional, cross-industry expertise which brings fresh perspectives and proven processes in addition to experienced PMs who can help you reach your goals.