I have to admit to a strong bias up front: I love Apple. I think they’re responsible for some of the best technology products our industry has produced in the past 25 years, and I have been a fan of the company since the Lisa (which I consider a prototype for the Mac). I view Steve Jobs as one of the best product managers of all time.
In the last article, we discussed techniques for getting stuff done in a large company. Now I’d like to talk about the related problem of innovating in a large company.
Many of my readers work in large companies, including Adobe, Amazon, AOL, Apple, eBay, Google, Microsoft, PayPal, and Yahoo, and two of the most consistent themes from your questions and comments are: “how do I get things done in a large company?” and “how do I innovate in a large company?” In this issue and the next I want to tackle these two related topics, as I have worked in several large companies, and while it’s not easy, I do believe that those that figure out how to leverage the considerable resources of their company bring a substantial advantage to their product.
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.