In earlier articles I have discussed the key roles in the product organization – product managers, project managers, interaction designers, visual designers, usability engineers, prototypers, engineers, architects, QA and product marketing – and I’ve also discussed the ratios between the roles, but many organizations also struggle with the organizational structure that contains these people.

While I have seen - and continue to see - many different permutations out there, I do think that a standard organizational structure for product organizations has emerged over the past several years, and that there are good reasons for this structure.

I will admit that I do not feel nearly as strongly about the organizational structure as I do about the roles and responsibilities. I believe that if you have the right role definitions, and reasonable and well-intentioned management, you can usually make most organizational structures work, and I have no real problem with designing an organization around the strengths of the individual leaders rather than following a template from successful product organizations.

That said, we all know that organizational structure really does impact behavior, so all things considered equal, I argue that evolving towards the structure I describe below will improve the effectiveness of your overall product organization, sometimes in very profound ways.

Please note that I am only talking here about the product organization and not the other major areas of your company including sales, customer service, finance, business development and IT (as distinct from product development).

I argue that every CEO/COO or division GM needs three clear and distinct voices on his staff: Marketing, Product Management and Design, and Product
Development. As such, the most important aspect to the organizational design is that these three be top level, and one should not be buried within another.

So, reporting to the CEO/COO of a small or medium sized company, or each business unit GM of a large company:

- Marketing contains functions including corporate marketing, marketing communications, field marketing, and product marketing.

- Product Management and Design contains product management, user experience design (interaction design/information architecture, visual design,
prototyping, user research/usability engineering), and if applicable, subject matter experts.

- Product Development contains architecture, engineering, QA, release management, site operations (for SaaS companies), and project management
(PMO).

Notes:

- Notice that IT (the technical team that supports employees) is intentionally distinct from the product development organization. This is the topic of a future article, but for now let me say that the demands on these two groups are inherently different, and that it’s important to treat each appropriately. In terms of titles, normally the CIO runs the IT organization, and the CTO/VP Product Development/VP Engineering runs the product development organization.

- In some companies, the PMO is a top-level report and this is fine. But most often it’s part of the product development organization because the
vast majority of the resources the project managers deal with are part of that organization, and this allows the head of product development to be fully empowered and accountable for product execution and delivery. In any case, it’s important that the projects managers report into the PMO.

- It is a problem if User Experience Design is buried either in marketing or product development. It is critical that the user experience team,
especially the interaction designers, be very closely tied to the product managers. Keeping product managers as close as possible to the UED team is the reason for the trend towards combining product management and design into one organization (although each should have its own leader – the
director of product management is responsible for product strategy, and the director of user experience is responsible for the site/software overall information architecture and style.

- Marketing typically also has some number of graphic designers that support marketing programs and advertising. This need might be served out of the visual design team in the user experience org, but I prefer if they are a part of the marketing organization. A strong user experience requires
constant attention not just to the interaction design, but also to the visual design of the application, and this group should be managed by someone who understands what it means to support a product team. If there is a single Creative Director who understands both visual design for product, and visual design for marketing, the company is in great shape because one visual design group can serve both needs, and the overall expression of the brand will be very consistent. But if the head of the visual design team is under marketing, and isn't understanding the needs of the product, you will need to correct this situation as soon as possible.

- User research is sometimes separate from usability engineering, which is fine. But do not confuse user research and usability research. User research is background data on the demographics of the customers, or analytics of the customer’s behavior or buying patterns. It is not unusual to find user research as part of the marketing organization, which works so long as the product managers and interaction designers have ready access and a good working relationship with the user researchers. Usability research, by contrast, is specific research on personas, prototypes, or users' ability to easily navigate the product. These researchers' work feeds directly back to the interaction designers, visual designers, and product manager, and it is critical that they be an integral part of the user experience design team, so that their efforts can be collaborative and their research windows scheduled and closely managed to get feedback quickly during product discovery.

- Sometimes product marketing is part of the product management organization. This is not a big problem, and there are some advantages to that, but I prefer when it’s part of marketing as this helps to reinforce role definition and make sure there’s no confusion between product management and product marketing. To be clear though, even if product management and product marketing are part of the same organization, the roles should not be combined.

- Startups are a bit of a special case in that they are typically small enough that the organizational structure is minor compared to the personalities and individual skill sets involved. But remember that if things do go well, you’ll grow fast, and you’ll want to put an effective organization in place sooner rather than later.

If your organization is not structured in this fashion, then if things are working great I would not suggest changing a thing. But if your team is struggling, and if it feels more painful than it should to get good products out the door, then consider evolving your organization more towards the model described here and see if that doesn’t improve the situation.

Special thanks to both Chuck Geiger and Kyrie Robinson for their contributions to this article.

Email to a friend

Sign up for the free newsletter here.

I’m not sure how many of you have heard the phrase, “we eat our own dog food,” but for several years at least, companies especially in Silicon Valley have used this phrase in order to impress their customers that their product is so good that they run their business on it and use it themselves. This was practically a mantra at Netscape, and I can’t count how many times I’ve said this myself.

Today, I’m embarrassed to have said something so meaningless. Of course we used our own products. It would have said much more about the state of our products if we couldn’t use them. And yes, of course you should use your own products, but you need to realize that it’s just another form of QA. Just as you wouldn’t brag that your software passes unit testing, you don’t need to brag that you can actually use it.

But the real issue here is not the importance of running your own software. The real issue is that this is just another symptom of a big problem we have in our industry, but especially here in the valley. We tend to believe that our customers and users are much more like ourselves than they really are.

If we like it, and we can figure it out, then others will too. The problem is that this just isn’t true. Yes, there are some niche markets like developer tools where it is somewhat true, but even there it’s less true than you may think. There are several reasons for this.

First, realize that not only do you not have to pay for your own software, but in fact you are paid to use it, as employees. It would shock me if SAP doesn’t use their own software to run their business, but it means nothing to me that they do. Their employees essentially have a blank check to make it successful. But their customers don’t. Imagine the SAP employee struggling with the product, and getting to the point where he says to his manager he wants to switch to Workday. Do you think that’s likely to happen? Of course not. But do you think this could happen at their customer’s site. It can and is happening.

Realize that your company’s employees are much more vested in your product and company than your customers, and that means you’ll tolerate more, much more than your customers.

Second, if we have a problem or a question, we can just go ask the developers. Your customers can’t. They have to read manuals, attend training classes, sit on phone calls with customer service, or sift through forums with other customers struggling through their own issues. Frustrating and time-consuming, and detracting them from whatever their real job is.

Third, a great many of us in tech companies are early adopters by nature. I know I am, and I also know that this means that what motivates me is going to be very different than what motivates target customers. This is a big reason why I like personas as a tool for calling this out.

But the bottom line is that all this points to how absolutely critical it is to test your ideas and your product on real target users and customers. If you haven’t been surprised by how different a customer’s response to your product is, then you probably haven’t yet done this type of testing.

Remember also that when you do this testing, it’s not enough just to get your product to the point where the user can figure out how to use it. You also have to get the product to the point where the user chooses to use it.

Email to a friend

Sign up for the free newsletter here.