Published in


11. Chief Information Architect

Depending on the size of the product team and its position in the organization, the leader of the team might have any number of different titles: chief product officer, vice president of product, director of product management, even group product manager. Sometimes the title is just Head of Product, leaving the exact level ambiguous.

In some organizations the head of product or CPO has a design peer, a Chief Experience Officer (CXO) or Chief Design Officer (CDO), or Head of UX (or Design), but this structure is (sadly, for UXers) still more the exception than the rule. More often, both UX and product management ultimately roll up to a head of product.

Thus, if you do choose to pursue a product management career founded on your UX expertise, then the promotion ladder will potentially take you to a product leadership role, where you may find yourself (once again), managing designers alongside product managers and likely some other skillsets as well (data science and analysis, customer success, maybe even some engineers).

The head of product’s secret sauce

When the internet first took off, the people doing what we now call user experience strategy, research, and design were called information architects. Over time, new roles and titles came along (interaction designer, UX designer, product designer) and the role of an IA was gradually reduced to either “figuring out the navigation” for websites or limited to information-rich environments that need the library-science skills of taxonomy, ontology, synonym rings, and the rest.

But along the way information architecture also reasserted itself as a discipline in its own right with important things to say about notions of space, embodiment, information, and wayfinding. As discussed in earlier chapters, the IA practices of mapping systems to reveal their concepts and meaning and providing a coherent picture and story about what the team is actually building turn out to be crucial skills to bring to bear to product management at every level.

Years ago, when I was working for one of my product mentors, Matte Scheinker, in an attempt to reboot AOL (now finally absorbed into Yahoo and sold off to private equity by Verizon), I told him I was surprised that we didn’t have information architects on staff, as it wasn’t even a job title in the HR system anymore.

Matte (pronounced “mott-ee”) turned to me and asked, “Well, how many IAs does a company need?” So I thought about that question before answering and then said, “At least one.”

This got me thinking that in the company needs to be the chief information architect and do the hard work of mapping the problem / opportunity space and the meaning and purpose of the product in that larger system.

There are many organizations where nobody does this work for the product or portfolio as a whole, even if lots of really good UX designers and PMs are thinking intelligently about the IA and structure of their specific features and projects. If anyone is telling that larger story, it tends to be the head of product (or sometimes, for sure, a head of design).

Someone needs to take responsibility for the coherence of the product at the highest level. Information architect and consultant Jorge Arango put it this way in his Informed Life podcast in 2020:

This “decoherence” among versions of the same product is a consequence of fragmented pressures from different platforms, tech stacks, and user bases.

There are natural tensions even when trying to impose a consistent paradigm across a family of related products. Individual teams will object, saying “Yeah, but that doesn’t work for my device,” or, “But I have reasons for this,” or “It’s always been this way on our sub platform. You bought us and now you’re trying to make us be part of you.”

Especially in a larger organization, where everything’s constantly shifting, it’s almost impossible to impose coherence from the top down, but a product leader can gradually maybe bring a complex system into harmony.

It often seems that every big organization is literally either in the process of becoming a little bit more decentralized or a little bit more centralized, or it’s finished doing one of those things and it’s about to start doing the other one. They never find the perfect amount of decentralization and centralization, and so you get matrix reporting. People end up with both a boss and a practice leader, and during reorgs they vibrate between reporting to one or the other primarily. Unfortunately, this kind of organizational thrash also tends to produce product experiences that are all over the map.

Ideally, you are shooting for a holistic UX instead of a unique experience for each expression of your product. Meaning that you don’t do the UX of your Kindle on the Mac and the UX of your Kindle on the Kindle and your UX of the Kindle on iOS, and the UX of the Kindle on Android devices, and so on, each as separate exercises managed by siloed teams.

Kindle should have one UX, and Kindle should have an information architecture that is one big map. And then everything should be some articulation of that or some expression of that. There will be compromises, but there should always be a larger sense of unity and cohesion. Without someone in product leadership focusing on this goal and working toward it, drift is inevitable.

Be a Boss

For years UX fought for “a seat at the table,” or to be in the room where it happens. Along the way we started forming product organizations and it seemed that most UX jobs had a reporting structure that eventually reached someone in a product role. To get a seat at the boss’s table, it can feel like you need to be a product leader.

Now this is changing somewhat, to some extent, in some contexts. We have design executives and organizations where product and UX design sit together as peers at the very highest level of the org chart, but in either scenario, all roles converge at the leadership level. Whether you come in the door wearing a product hat or a design badge, you sit down together and come to decisions about product and organization strategy together around the same table. You each bring your expertise and the ability of your team to deliver to that table, but by the time you get there it might not matter as much to you which door you came in.

Then again, in many organizations, the top dog in the shared space of product and UX still has a product title. This is not the best reason to choose product over design at the fork in your career road, but it is a legitimate consideration. If your organization needs product leadership, if it needs an information architecture mapping and clarifying the product roadmap, why shouldn’t that boss be you?

Just remember that once you climb that pinnacle, get a seat at the table, and have a voice in the direction of your product, all the most difficult decisions are going to come to your desk, and it’s going to be you awake at 3 am remembering problems nobody else is worrying about (Figure 11.1)

Figure 11.1: Careful what you wish for! By the time you become the boss of product, you inherit all the biggest problems and all the riskiest decisions.

Selling Your Team’s Services Internally as a Product

One of the most reliable forms of advice an experienced practitioner can give an up-and-coming UXer is to apply their user-centered research and design “superpowers” to more problems than just the design of interfaces and software product experiences in general.

As you progress in this world of collaborative technology development, you will notice along the way that the difference between success and failure often has a lot more to do with “soft skills,” team performance, and interpersonal dynamics than the tech stack or navigation paradigm you choose.

One of my clients, the state of California’s Office of Digital Innovation, for example, builds and ships digital software products in the sense that most people mean, such as the state’s pandemic response website (, shown in Figure 11.2, and forthcoming site for the state’s cannabis licensing authorities ( and to help the state’s public conserve water (

Figure 11.2: California’s Office of Digital Innovation (ODI) spun up the site in response to the pandemic to provide the state’s public and government officials with a single reliable source of current guidance and information.

Those websites can be thought of as products in a more-or-less-traditional sense, despite the lack of any commercial transactions or consumer goals (though the Cannabis site will enable license applications), but the deeper mission of the innovation team is to help enable all of the state’s agencies to produce highly performant, very usable websites that communicate in plain language and make data open and accessible.

For this goal, the “product” is more a set of beneficial practices and some tools and services (such as a design system and consulting resources), and the “customers” are colleagues in adjacent state agencies. Here again, the product management (and leadership) superpowers of

  • deep curiosity about the needs of the person we are trying to serve
  • rapid iteration through a build / measure / learn cycle
  • thoughtful communication, illustration, and storytelling

enable us to meet the demands of this internal “market.”

Frankly, all teams need to do a certain amount of this, persuasion of other teams and leaders as to the value of your skills and talents and offerings. It’s just the the UX and product superpowers are particularly helpful when your train the lens on your surroundings as well as your external markets.

Overcommunicate deliberately

Fundamentally, successful alignment within a larger organization comes down to communication, making sure the work your team does is “legible” (clear to read, and easy to understand), always staying ahead of changing circumstances to keep expectations current, and overcommunicating wherever possible.

For example, if you lead a product team you should plan a regular cadence of sharing out updates on the product roadmap, showcases of the work currently underway, and retrospective analyses of the outcomes from what was shipped in the past.

Partner with the voice of the customer

It’s shocking how many organizations keep their customers at arm’s length. Even when there are teams dedicated to supporting or otherwise interacting with customers, they are often siloed off away from the rest of the organization and treated more like a cost center than as an invaluable source of research, let alone the external nervous system of the org itself.

Years ago, Craig Newmark, founder of Craigslist, made a point of focusing on customer support instead of making himself CEO of his own business. He made a strong case that the only way for a collective entity such as a business or enterprise to actually learn and evolve is to channel feedback from externals signals directly to the decision-making center. He championed empowering customer support professionals to report what they were hearing and to propose solutions.

Whatever the prevailing culture you find yourself in, part of your mission will be to forge ties with customer support, customer success, and community managers. These people can offer you solid gold insights into what your customers and larger community of supporters want, need, talk about, complain about, love, hate, and trend towards.

Any product success I’ve ever had has derived at least in part from close collaboration with customer support and community managers, leveraging their access and analyses to form a deeper and richer picture of where the product needs to go, and even working directly with customers in the product’s community, gathering their wishes and feedback, sharing early design sketches with them, recruiting beta testers, and enlisting supporters to help spread the word.

Building Product Teams

Once you’re running a product team, you’re in the business of hiring and building the strengths of that team. Creating a strong product organization starts with a commitment from the top, and now this will mean from you.

Change is never easy and new habits cause friction when they clash with comforting older customs. Your executive championship of the product mindset will be a necessary, but not sufficient, ingredient in transforming your business and empowering your product people.

Define the skills your product team needs to bring to bear, make some skills histograms (as explained in Chapter 3), and start recruiting to hire people who can help your team level up in the critical areas where you are not collectively strong enough yet. Also, look for the product people who are currently in other roles. Some will be participatory allies and part of the product culture you are hoping to grow, and others may be great candidates to move over to the product track under a leader who can help mentor someone through such a change.

Enabling transitions

When you are growing a product team out of the “soil” of your existing staff, you will want to identify people who show the sort of aptitude and instincts discussed throughout this book. They may be engineers, designers, marketers, business analysts, project managers, sales people, customer support staff, or really anything.

Make it clear that you are building a product practice and that it will involve some hiring and that people in other roles will be involved as the entire enterprise takes on the habits of a product organization, but that you also welcome people formally transitioning into product management roles, and will facilitate this by providing training, coaching, and mentorship.

Investing in your team

Constantly look for ways to develop product . Product people need to master these skills and techniques discussed throughout this book, and you need to help them do that. Product leadership needs to put in place the educational opportunities and events, the training programs, and to build an operation that provides career growth and professional development for product practitioners.

Product training should be offered to any practitioner who is interested, not just to people with product manager job titles. The goal is to nurture and validate product mindset in any role, across the entire organization (Figure 11.3).

Figure 11.3 Atlassian puts on an internal product craft conference annually to train product people and build the product practice community across the company.

Cross-training for increased fitness

A reliable way to broaden and strengthen product skills across your org is through cross-training. This depends on having at least one person who has mastered the skill that others are hoping to develop. Let’s take for example, tracking product analytical data, such as retention, and working systematically to improve it.

This is an activity that involves a handful of techniques and skills that can be learned, among them:

  • capturing valid meaningful data
  • manipulating charts and graphs to analyze the data
  • engaging in discovery to understand what is going on with customers that might explain the data
  • developing hypotheses about what might improve the experience
  • prioritizing experiments to test these hypotheses
  • learning from the outcomes of experiments and feeding this learning back into the discovery process

The best way to cross-train a product person who is more junior or who has less experience with these activities is to pair them with a senior product person who excels at these things. The key part is that the person who is learning does the work. The person who has the wisdom and experience provides coaching, guidance, and feedback.

In the short term, these tasks will take a bit longer than if they were assigned to the experienced hand, but the benefit to distributing this expertise more widely on the team outweighs this cost, and the more cross-training goes on, the more supple and agile the product team will be, more able to flex, recombine, and adapt to handle changing circumstances.


Whatever path you decide is right for you, every effort you’re part of it is going to need someone to be that chief information architect, whether that’s the head of product, the head of product’s design right-hand thought partner, or the head of design. It all comes together at the top.

Key Insights

  • Information architecture can be a unique superpower for a product lead
  • Whether you become a PM or stay a UX designer in a product world, you can still get a seat at the table
  • As a product leader, one of your products is your team, its customers are your colleagues, and its market is your organization
  • Make sure your work is legible and you overcommunicate
  • Product leadership means building the scaffolding for the development of more product talent
  • Be a boss

Product Management for UX People



product people cultivating product mindset doing product design

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
christian crumlish

Product leader, writing Product Management for UX Designers (Rosenfeld Media) and Growing Product People (Sense and Respond) — more xian