In the previous article I argued for some very significant changes to the way most teams produce software. Several of you wrote to me and asked that I elaborate on my final point, which had to do with the fact that once you have a product definition that works, you can’t just “piecemeal” it up and expect the same results. I believe this is a hugely important point, and gets to the underlying reason for a great many failed products and wasted releases.
I do not believe great products happen by accident. In every case, behind every great product I find that there are certain truths. Today I want to share ten such truths. I try to keep these in mind on every product effort:
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.