This year's data model Since there are no industry-standard approaches to product requirements, most PM organizations improvise the data model for product requirements. As with any data model, over time, requirements information evolves. Even though PM teams craft their own data models, these evolutions seem to be pointing in some common directions.
Therefore, I'll be writing a couple of posts about these evolutions in the PM data model. Right now, my data is very impressionistic. Whether or not this topic turns into some serious research, I'd be interested in hearing what you, Dear Reader, think about the requirements data model. Please voice your agreement or disagreement to the Comments section of this post.
Sometimes, these common directions in the requirements data model reflect outside efforts at standardization. For example, the Six Sigma approach suggests that you should track particular kinds of information. If you're in the minority of product managers who use a requirements tool, you'll have a data model suggested for you, in the design of the tool itself. (Though you'll need to morph that data model into your own version, which is one reason why customization options are critical for requirements tool adoption.)
Actually, it's a double feature. Two research documents are in the editing process:
The long-awaited results of our survey of product managers, in which we ask what they do, to whom do they report, what are their chief concerns, and how does any of this resemble what they think product management should be.
A shorter piece on what makes the technology industry (TI) different from other markets. (Spoiler alert: Rapid innovation isn't 100% wonderful, but there are easy ways to avoid the bad side-effects.)
Maybe it's just me, but I seem to have bumped into a lot of people in the technology industry who think that innovation and customer sensitivity go together as well as Batman and the Joker. (Spoiler alert: Innovation is the good guy.) In this worldview, customers can't understand innovative ideas, because there's no reference to them in reality as it exists today. Innovation is just too...Er...Um...Well, it's too damn innovative for the average person to understand.
According to a different point of view, as expressed in this post on Derek Morrison's blog, if you spend time with customers, you'll find inspiration for new ways of helping them that you never would have conceived on your own. Customers are not objects to be overcome; instead, they are wellsprings that you can help channel.
Which is right? It depends. On the one hand, I've seen people fail to understand Big Ideas until they saw it in action, at which point, they loved it. The iPod was one of those Big Ideas. XML was another, something that a surprising number of developers didn't get when they first heard about it.
I do in fact recall when I was first put into the role. It was exciting, but at the same time, really ridiculous. Not for any other reason than, I wasn’t working for a more senior product manager to kinda guide me a long and instruct me on what to do - I was in there on my own learning as I went. It turns out, this is ideal for me, but I recognize it’s certainly not everyone’s cup of tea.
This leads me to admission number 1: The job is damn near impossible when you first start. Actually, scratch that — it’s damn near impossible when you get 3-4 months in. This is because, at least from my experience, it takes people about that length of time to really wrap their heads around what it is they are supposed to be doing. And I believe this is where most would sink and maybe start believing, “this job is WAY too hard for me, or anyone, to really do.”
What makes the technology industry unique, and where in that marketplace you might find untapped opportunities.
What do product managers do on the job, and how does that compare to what they think they should be doing? Looking at this picture, how can you revise your product management organization to make them a more strategic resource?
Just got back from the Cambridge office, where we held a one-day workshop on crafting a sharper value proposition. It's one of several dimensions of our "messaging review" methodology.
Working with hundreds of technology vendors, in thousands of interactions per year, you quickly identify the common pitfalls. Over time, Forresterites have developed a rigorous way of breaking down marketing messages into their components, evaluating them, and helping reconstruct them into something better. (There's even a nifty diagram that displays the strengths and weaknesses of the current messaging.)
Beyond the more scientific process of evaluating marketing messages, there's also the "Eureka!" or "Aha!" moment that's harder to quantify. This threshold is easy to describe: the moment when you start thinking in your target customer's terms, not your own.
Initially, it's hard to do--almost like learning a new language. Just as you need to learn a new syntax and vocabulary for a new language, marketing people have to learn about roles, business problems, evaluation and adoption processes, and other details. Fitting the technology into these sociological realities is the next step.