Even in small companies, getting decisions made is often time-consuming and frustrating. Every product company needs a mechanism to get the key stakeholders and decision makers together to make timely and informed product decisions.
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.