Recently I’ve written about reinventing the product spec, and the reasons to move from a heavy-weight PRD to a light-weight high-fidelity prototype as the basis for your product spec. But where do these ideas come from, and how do you decide if you even want to build a product in the first place?
It’s funny how often I’m asked whether I am a “strategy guy” or an “execution guy.” I completely understand the reason for the question, as I think it’s true that most people prefer one or the other; in fact, they often very strongly prefer one or the other, or regardless of their preferences, their personality is only suited to one or the other. Yet for product leaders, it has always been very clear to me that you must be skilled in both in order to actually get good products launched.
One of the most common situations today is where the product manager is in one location, and the engineering team is somewhere else. I don’t only mean outsourcing to India either – the remote development team might be a consequence of an acquisition or merger, or possibly your organization is large enough where the developers are centrally located in a facility somewhere you aren’t.
I think the product spec is long overdue for a renovation. Some would argue that Agile methods accomplish this by doing away with the spec altogether. I’ve written about some of the issues and limitations of Agile methods elsewhere, but in many respects I think they were on the right track.
Do you ever feel like you come in early, work frantically until late in the evening, day after day, week after week, yet at the end of the month you didn’t get anything important done? Is your day packed with back-to-back meetings, with bursts of e-mail in between? If so, you’re not alone. Especially in larger companies, the life of a product manager or designer can be meeting hell.
The last note discussed the different types of user interface design – interaction design and visual design – and tried to make the point that both are required for a good user experience. But the response surprised me. So many people wrote to me to complain that their company essentially doesn’t do either type of design, and they know their product suffers for it. Most said that the UI engineers just did whatever they could and that was the design. Sometimes the product managers waded into the design waters and did what they could. Some companies try to outsource some visual design at the end of the process, just before the product goes into QA. Some people that wrote to me said they had no idea what any of these roles were.
I think most would agree that the general state of web site design is still in its infancy, at least as practiced by most companies. While there are some notable exceptions, many sites, even from major players, are often either very difficult to use, downright ugly, or both. I’ve been thinking a lot about this lately, and I have formed some theories as to why so many sites are bad, and what it will take to make this a better world as we all spend an increasing amount of our life interacting with the web.
In many product organizations there are problems between product and marketing. The problems might range from mild friction to downright dysfunction.
Normally I focus on the product definition aspects of creating successful products. My reasoning is simple: it doesn’t matter how great a job you do in building your product if it isn’t the right product. That’s really the role of the product manager; to define the right product at the right time. However, there is one little detail that too many product teams seem to miss, even when they define an otherwise excellent product. That is, the product has to actually work.