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.
Early next year Rosenfeld Media will be publishing my book Product Management for UX People: From Designing to Thriving in a Product World (you may sign up there to be notified when it is available for order), the culmination of a multiple-year project that has unfolded with the input and support of the Design in Product community.
During the editorial and production process I am sharing early drafts of chapters, and I welcome any feedback here that will strengthen the material.
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 any 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 somebody 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:
“Where within this [product management] framework is there place for looking after the coherence between those things? Especially if they’re part of some kind of ecosystem or family of products. Eventually those things need to cohere at some level….
“My favorite example of the lack of such a thing is Kindle. I’ve been using Kindle for a while to read books, so I should be familiar with it. And I use Kindle in three very different device platforms. I have a dedicated Kindle reader, I have Kindle on my iOS devices, iPad and iPhone. And I also use Kindle on my Mac, and I find things like navigation structures to be different in all three.
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.
I would argue decoherence is also born from org structure and internal funding models especially in companies/products where many lines of business live under one brand. For example, at CVS Health we offer flu shots through both the pharmacy and our Minuteclinic. Same shot, same topic, even same location, but different lines of business. So without a chief architect that “looks across” these lines of business to drive coherence, we’ve ended up with two ways to schedule a flu shot on one domain, placing the onus on the customer to navigate and understand.
— Dawn Russell, information architect at CVS Health
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)
From the Trenches
Harry Max is a leadership consultant who has guided many product and UX leaders.
If you want to be taken seriously and you want a seat at the table and you want to start dealing with executives, you have to start speaking the language of business. You’ve got to talk about making money. You’ve got to talk about saving money. You’ve got to talk about avoiding unnecessary costs.
You’ve got to talk about building brand, building market share, hiring and retaining talent, and identifying, pursuing, and executing goals and objectives. You’ve got to figure out how to make progress day in and day out, period, and you really have to step outside yourself and start looking at how you’re communicating.
It starts with speaking the language of the people that you’re interacting with. And if you’re doing it in a for-profit environment and you’re doing it in a business, you really have to use the language of business. And if you’re doing it in a civic-oriented environment, you’ve got to start using the language of policy, the language of constituents.
You have to get inside the head of the people. UX people often speak the language of design and visuals and information architecture and usability. Leaders are trying to figure out how to steer an organization in a direction. They’re responsible for people, they’re responsible for projects, they’re responsible for money. They’ve got lots of constituents, whether they’re investors or bankers or whoever
Your listening skills have to shift. You’ll have to discern things at a higher level of abstraction. You have to get beyond active listening and move into what I characterize as “deep listening.”
The higher level you go, the more the people that you’re communicating with are going to work to move a conversation forward, because they are discovering what it is they want to learn as you’re talking, which means that when they’re asking you questions, you have to answer the questions they’re asking, not the ones you were trying to answer yourself. You’re answering very precisely, and you’re anticipating to some extent where they might want to go so that you can be efficient about helping them get there, but you’re not telling stories!
You’re not giving these long preambles and you’re not giving a lot of excuses and it’s not because they don’t want to hear excuses, which they don’t, but it has to do with the fact that what they’re really trying to do is get to something that’s meaningful and interesting. That helps move the conversation forward for them.
So precision questioning and answering deep listening are critical too. I think it’s especially true of designers who are interested in pursuing more responsibility and higher level goals, because the expectation is already there that they’re good at it. And if they don’t do it, they’re being doubled downgraded for it.It’s going to boil down to: Are you in a position to make clear the requests, and accept and deliver on agreements that you’ve made? Can you draw a through-line from a thought to a conversation to an action, to a decision, to a request, to an agreement? Do you understand the outcome frame around that? That is, what does success actually look like and how do you clarify it for yourself and for others?
How do you avoid tacit agreements? “Hey, I realized that when we were talking about this, that, you know, you asked me to do something and I needed time to think about it, but I just realized that you probably left with the impression that I’m actually going to do this, and I don’t even know when you want it done.”
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.
UX Superpower Alert
If you’ve ever had to sell UX in an organization new to it or reluctant to embrace it, then you’ve seen that arrogant evangelism backfires, but that deeply understanding the needs of your users, er, colleagues, reflecting on the “usability” of your deliverables and communications, and crafting an experience (of working with you) that delights, relieves pain, and solves real problems is the path to success.
The same “advice” trick applies to job searches and getting better at interviewing. Take all your abilities to understand people’s needs, motivations, worries and fears, and to shape experiences designed to address those needs and apply them to the experience of hiring you. Lather, rinse, repeat.
So it is with product management, where the disciplines of obsessing intensely about the unmet needs and aspirations of your “customer,” crafting a solution that addressed the demands of a “market,” and packaging your services as a “product” can be turned to other goals beyond enticing people to complete transactions.
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 (covid19.ca.gov), shown in Figure 11.2, and forthcoming site for the state’s cannabis licensing authorities (cannabis.ca.gov) and to help the state’s public conserve water (drought.ca.gov).
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.
A Day in the Life of a VP of Product
Benoît des Ligneris, Vice President of Product at Woolf
Share anything else that might help describe the environment in which you practice product management: Hyper-growth industry with lots of innovation and competition.
How do you spend the early morning? Waking up with the sun, meditation 20 minutes, chores, strength training / bike ride / run then walk 30–45 minutes then work from home
How do you start your workday? By a 30 minute walk outside to plan my day and solve problems or define goals
How do you spend most of the morning? I do not have a typical morning! I have lots of meeting and try to get them early in the week.
Monday-Tuesday morning is when I tend to have my key meetings outside of the product team.
Wednesday is “no meeting” day: Only craft-based activities (to become a better PM, not to PM something…) in the morning
Thursday: Recruiting and peers .
Friday: This is when I have my meeting with senior leadership, I try to focus on this.
How does the morning end? Noon. I have it in my agenda: no meeting during lunch time. Especially working from home it is important to have boundaries and key rituals in place. Most of the time, this is a meeting with someone from my team. I like the idea to wish folks “Bon appetit” and share some detail about our daily lives.
When do you take a lunch break, and what do you have for lunch? Noon. I typically spend 30 minutes to eat and then go for a walk outside (whether -30 C or +45) with my wife: Non-negotiable “us time.”
What do you do first in the afternoon? Lots of key meetings with other teams and customer sessions tend to start at 1PM sharp. Everyone is quite productive after lunch.
How do you handle “firedrills” or other unplanned work? My limits for a productive Monday are between 7–12 meetings as I try to gather key information for the week + I try to book all my extra meetings the Monday so that I can organize my week around this new information. The other days, my schedule is lighter with 4–8 meetings maximum. Because Wednesday is “no meeting day,” it nicely cutx the week in half and help create some slack in my schedule.
How do you spend the bulk of the afternoon? Being a morning person, I am less productive in the afternoon and I tend to keep it for the more tedious work/ work that is automatic and/or that I enjoy less in particular:
reporting
status update
checking KPI
updating documents/iterating on feedback
What do you do at the end of the workday? I also do my best to stop at 5PM sharp. It does not happen all the time as lots of candid conversations tend to happen at the end of the work days. Especially for my reports. Lots of the emergency also require a kind of end of day check-in to align for the next day. Those are the two occasions I allow myself to work past 5PM.
Do you work in the evening? Occasionally
Investing in your team
Constantly look for ways to develop product craft. 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).
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.
Remember
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
—
You can sign up to be notified when Product Management for UX People is available for order at Rosenfeld Media.
