Six years ago, I came aboard as the sole project manager at Bytemark. It was a project in itself, just explaining the role and my expectations.

In one of my first weeks, a developer told me, “We work on what we want to, when we want to, and we will let you know when it’s done.” To which I replied, “I’m sorry, but that’s not how real life works.”

Clearly, my role was needed; rather, an entire department was. Over the next few years, I built up the project management department, and, with the help of those on the development side, we started a sprint cadence, implemented a universal tracking system, and reorganized into cross-functional scrum teams.

It was a start.

However, projects still took too long, and they didn’t always come out right. It wasn’t for lack of direction. We would get lists of requirements, sometimes even with a pre-prescribed implementation plan. It seems like so much detail would be helpful; we didn’t have to think, we just had to do. But the end result either slightly missed the mark or couldn’t be reused for other clients, or both.

It seemed like the clients, the project managers, and the developers were all speaking different languages. If not, how else to explain the disconnect?

We Were Missing Product Managers

At first, this seemed silly. Product managers are merely a mashup of developer, designer, and project manager, and we already had all those roles. “Project” and “product” even sound the same; it’s just a two-letter difference.

If we absolutely had to have product managers, maybe we could promote developers. Maybe we could reappropriate a couple project managers. It seemed somewhat logical but doing so would be the equivalent of me suddenly declaring I was going to be an iOS developer.

The issue, you see, is not that project managers, clients, and developers speak different languages; it’s that they are concerned with different questions:

Developers want to know “how?” How do I achieve the expected result, given a set of inputs?

Project managers want to know “When?” When can you start? When can I get it?

Clients want to know “what?” What do you have to offer? What am I getting?

Product managers, on the other hand, ask “Why?” And then sometimes we ask “Why?” again. And again. And … again.

Why, you ask? Let me give you a possibly overlong example.

Ask Why, and Ask Again

I’m in the second year of pursuing my MBA, and we recently completed a set of classes called “Innovation and New Venture Creation” and “The Customer Experience.” We knew these classes were coming, and we spent our first year discussing what sort of awesome inventions and genius businesses we were going to create. Let me tell you, the ideas I heard were neither awesome nor genius. And it was all for naught anyway when the professor started the class by insisting that we would not be thinking about products for several months. Instead, each group had to pick a clearly defined customer segment and talk to them.

“Talk to them about what?” we asked.

“Just talk to them. And then, when they mention something interesting, ask, ‘Why?’ And then when they answer you, ask them ‘why’ again. And then again.”

“You want us to pick a random segment of strangers and ask them questions? And then ask them why, why, why, why, like a bunch of five-year-olds?”

“Yes.”

Clearly, we all agreed, this man was a crazy person. However, he also controlled our grades, so we found some random but very specific strangers and asked them questions. (My team chose female marathon runners who run at least two half marathons a year and have professional jobs.)

The goal was to identify the customers’ “hair on fire” problem, and then ideate a value proposition. Not a product, not a set of features, but an intangible benefit that we could possibly offer. Actually, the product itself was the last thing we discussed.

Before the holidays, teams presented their solutions. And yes, I say solutions — instead of products — intentionally. Presentations varied in quality, but several of the ideas were, in fact, awesome, and a couple may have verged on genius. We only got there because of the intense customer discovery we did first.

You can build any super-cool product you want. You can attach a blender to a sports car, and now you’re the only person with an excessively expensive blender that can go from zero to 60 in under 10 seconds. But if there isn’t a large, unmet need for sporty, high-velocity blending, no one is going to buy the product.

People don’t know what they want. Or they don’t know why they want what they want. And, maybe most importantly, they don’t know that they don’t know what they want.

As Henry Ford famously said, “If I had asked people what they wanted, they would have said faster horses.” The question that ties everything together is “why?” A different way to ask that is, “What job are you hiring this product to do?” The McDonalds Milkshake Marketing case study by late Harvard Business School Professor Clayton Christensen illustrates the importance of discovering the answer to that question.

Going from Product to Project

Bytemark has focused on modularizing the system and emphasizing configuration instead of customization. The payoff is huge: When I first started, the fastest we could get an app ready for testing was three months. Now, I can build an entire app myself, without involving any developer, within a day. Having a configurable, platform product based on a single codebase means we can respond to our transit clients faster, and everyone gets the advantage of the newest features, updates, and, yes, bug fixes.

I don’t want to build features transit agencies request. Those will arrive too late. I want to build things before they are requested. I want to know the “hair on fire” problem. Where are the gaps? What’s not being addressed? Why is something difficult? Why does something work well? I don’t know the answers yet. Heck, I don’t know all the questions yet.

In the new year, Bytemark will be rolling out a Product Advisory Board. We know how important it is to combine listening and innovation during the product-building process for agencies, and we rely on conversations to guide our product development. That opens pathways to innovation that a narrower, more prescriptive focus might not allow. Approaching things from a problem-solving standpoint also opens the door to greater collaboration.

Since reconceptualizing the way we deliver our mobility solutions, Bytemark has become a better transit partner with more capabilities, as seen with the successful rollout of Bytemark Bridge, our Plan, Book & Pay™ platform.

We’re no longer reinventing the wheel every time. We’re making it roll faster.

Stephanie Schrauth is VP, Product Strategy & Marketing, at Bytemark, a global innovator in Mobility as a Service.