Christian Crumlish has led product and design teams in organizations ranging from startups to large tech companies. In this conversation, we delve into the relationship between digital product management and information architecture, and how we might be more empowered as users of these systems.
- Christian Crumlish (mediajunkie.com)
- Dungeons and Dragons
- Design in Product Slack community
- Richard Saul Wurman
- Understanding Context: Environment, Language, and Information Architecture by Andrew Hinton
- Pervasive Information Architecture: Designing Cross-Channel User Experiences by Andrea Resmini and Luca Rosati
- Reframing Information Architecture by Andrea Resmini (Editor)
- Information Architecture for the Web and Beyond by Louis Rosenfeld, Peter Morville, and Jorge Arango
- Living in Information: Responsible Design for Digital Places by Jorge Arango
- Inspired: How to Create Tech Products Customers Love, Second Edition by Marty Cagan
- Shape Up: Stop Running in Circles and Ship Work That Matters by Ryan Singer
- Objectives and key results (OKRs)
- Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World With OKRs by John Doerr
- Amazon Kindle
- Matte Scheinker
- The Informed Life Episode 6: Beck Tench on Tinderbox
- From UX to Product (Christian’s video series in the UIE All You Can Learn Library)
- The Information Architecture Conference
- Web Directions Product
Show notes include Amazon affiliate links. We get a small commission for purchases made through these links.
If you're enjoying the show, please rate or review us in Apple's podcast directory:
This episode's transcript was produced by an AI. If you notice any errors, please get in touch.
Read the full transcript
Jorge: Christian, welcome to the show.
Christian: Thanks Jorge, I'm happy to be here.
Jorge: So, for folks who don't know you, would you please introduce yourself?
Christian: Sure. My name is Christian Crumlish. I'm a writer, product and UX leadership consultant, information architect and I guess I do other things too, but that's plenty.
Jorge: I've been privy to the arc of your career over the last, I would say 15, maybe 20 years? No, 15 years. And you're one of the folks out of several that I know that have focused on product. And I was hoping that you would tell us a little bit about that aspect of your work.
Christian: I'm glad it's only been 15 years, because sometimes the spans of time are starting to freak me out a little bit. But I think for me, a lot of what my title has been and what sort of roles or jobs I've done in companies and at other times as a consultant or you know, agency designer or strategist, the titles have evolved over time or changed. And in fact, when you mentioned that arc to my career, I thought like, if only you had my career had been in the shape of an arc, that would be so cool. Cause it's been more like a zigzag down or up, you know, along some rapids or something. I feel like I've shifted gears a number of times. I was talking to a D&D... A person who also had played D&D as a kid, and we were talking about the paladin-type character that you have to cross-train in like several different... You know, you have to learn, like to be a religious person and also a night and there's probably a third thing, and how it slows you down in a sense. You know, you don't do that. Like people who knew they wanted to go to med school when they were six and have stayed on that straight path their whole lives. My career has been like a path of discovery. But along the way, I've been given a lot of different titles, or I've asked for or invented titles as needed. And so, I was a content strategist back before that was almost even a thing, around 2000. And I was an information architect, and that was my title for a while. And I was a director of strategy, and I was in an interaction designer, and I was a design pattern library curator, or pattern detective, as I liked to say at the time. And along the way I started noticing that the frame of a product -- that talking about what was being made a software as a product -- was a fairly dominant kind of lens that was being used in the businesses I was working in. And I think I first really came to my attention at Yahoo when I was there for about three or four years. And the product organization was sort of on a par with the tech organization, the UX part of the shopper, UED as they called it, was itself really just a subdivision of the product organization, and ultimately always reported up to people with product management titles. The deep history of that at Yahoo was that they had people called "producers" early on, and in certain nineties in the web, if you made content there was often more of a television medium terminology and so producers of content. But half the people who had producer titles at Yahoo became front end developers because they'd actually been making the content, and the others evolved into the product management role. And that also took from a program management role at Microsoft. There's a lot of antecedents to this. But ultimately, the first thing I saw was that at least in these larger companies, user experience design was at the table, but they're sort of the kiddy table. And that they had these parents called product people. And so that made me think just from the desire to get close to the decision-making or to be able to make an impact, I thought, "I have to learn more about product, or why it's called product or what product management is." Along the way, these practices have continued to evolve and in relationship to each other. I think there's a very active conversation right now, about the boundaries or the intersection between product and UX. Enough so both, I witnessed this conversation and I have it come to myself personally when I speak, or when I'm out there connecting with people. So, I actually ended up setting up a community on Slack called Design in Product, just really to have a place to discuss that. And for some people that means kind of following this career path I've been on, of going from UX design or UX management roles to product management or product leadership roles. And other people deciding they don't want to do that, or they want to come back in the other direction. And a lot of negotiation over what is the shared common ground of those roles and where are their responsibilities and their points of view quite different. My roots go back to this information architecture tribe and people who have a point of view. And you and I have been friends for a long time, but I'm also essentially a student of your writing and your thinking and that of a number of other people who've really shaped my thoughts about information architecture. I don't know if other people call it this, but I sometimes call it like "third wave" information architecture, with the first being, of course, the initial... Spacing on the TED Talks fellow...
Christian: Yeah, sorry. You know, that's literally an architect saying, "Hey, making maps is really important," essentially. And that maps are going to be important information as well. And that they all sort of a share a semantic and kind of wayfinding and meaning-mapping kind of frame. And so, I think he kind of coined or crystallized the concept of initially. And the second way was sort of the world-wide-web-filtered application of information architecture, and just some often very tactical or pragmatic, but even then, with sort of this big-IA kind of dream of being the overarching backbone of things. And then what I think it was the third wave, is this sort of academically kind of sound and intellectually very rich notion of information architecture as still a way of mapping meaning and, and, and crafting spaces that are information, but I think less bound to some of the literal artifacts of the seventies or the nineties. And I don't want to do short shrift to other people who thought long and hard and debated these things. You kind of need to go to the books and read Andrew's books and yours and Andreas's and a number of other people to get caught up in that conversation. But I feel, again, that that conversation has a lot to say about product. And it's not just through UX. I mean, I think information architecture is a thing UX designers need to think about and be good at and use in their work. And UX then as a way of influencing the product management or product strategy and the product practices of companies. But I think IA is also a tool in the toolkit of the product manager herself. It's not just something that they should let designers mediate for them. I think they should be firsthand users. You know, architects of information -- people who think about the way the information and the meaning and the knowledge and understanding and the positioning of people's bodies and of spaces made out of information are going to play out in the product that they're building. If you were redeveloping the waterfront and putting hotels up and walkways and places for cars to drive, you know, you're thinking about how are human beings going to flow into the space? What kind of experiences are they going to have? What is it going to do to the economy? What secondary effects are going to happen? You know? And that's an architecture, traditional built architecture. And I think that when you're making software, particularly the kind of social software that I've typically been involved with... It's a metaphor, but it's not simply a metaphor. It's literally the same thing. You're going to build an environment. People are going to flow into it. They're going to have experiences. There are going to be secondary effects that you didn't anticipate and systematic ecosystem effects. And you need to do information architecture or have someone who's a really good information architect at hand, I think to get a grip on that. Or you make it sort of like primitive, you know, "We're just going to put the waste affluent in the river kind of kind of building." You know? Without thinking about the larger picture at all.
Jorge: You talked about how information architecture could inform the folks who are managing and designing products and building them. Because I'm on the IA side of things, I'm interested in the converse, which is about learning about product and learning how those roles work and how the process works. And in the past year. I've read a couple of books on this subject, and I have a specific question that I'm, I'm teeing up with saying this one is the second edition of Marty Cagan's book Inspired and the other is Shape Up by Ryan Singer from the folks at Basecamp. And one thing that struck me in reading both of those is that... And by the way, I'm not claiming that the latter uses anywhere near like the same framing as the Inspired book.
Christian: Right? Almost by definition it wouldn't.
Jorge: But I just bring them up because I see them as examples of what I see as advocacy for a type of approach to the work that is very much bottom up in my perspective, in that you're working within a relatively small problem space and you iterate on that. And you may be doing that in parallel to a lot of colleagues who are working in other projects of similar scope. And the question that I had in reading both of those books was, "Where within this framework is there place for looking after the coherence between those things? Right? Like especially if they're part of some kind of ecosystem or family of products. Eventually those things need to cohere at some level.
Christian: So, one thing about Marty Cagan is, anybody interested in product management should be familiar with Marty Cagan and should read his books and also follow him. He teaches, he's out there still influencing people. Silicon Valley-style product management is done in his image. It's done essentially in a framework that he established. It's also important to understand that he represents kind of a reforming notion of what product management should be from an earlier, slightly more, I'd say kind of enterprise, kind of static-MBA style product management. So, he represents the school of thought of, get outside of the building, and iterating on small things. Basically, in line with the lean and the agile trends that we all have probably been around and been part of it had been grappling with how do you do UX? How did you research? How did you plan? How do you think big or system systematically when things are being done often in these small incremental bits, as you asked? A big part of the product manager's role is actually connecting those levels of meaning, or those levels, those scales. There's this almost fractal-like scale of decision-making that goes on. And one great thing to know about product management as it differs maybe from UX and UX roles or your jobs, is that it's very much a decider role. You make decisions constantly. I don't like to stereotype people or professions or anything, but having been in them, maybe I'm a little bit more allowed to speak, you know, to tease ourselves. But what UX designers like to say, "it depends." They don't want to get things wrong. They want to figure it out correctly. They want to apply the proper techniques. They want to take time and do things well. And I think that that's an important set of values and forces to have represented in the process. I think product managers or product management does not always value all of those things as much and believes that you get diminishing returns and that being decisive sometimes with less than complete information is sometimes more important than being 100% sure about what you're deciding. And that comes from having to make decisions all the time. If you make, if you make 15 decisions in a day, you can't fool yourself into thinking that they're all 100% right and perfect. You have to know that you're going to have an error rate, and hopefully you keep it manageable and you're good over time. Just to go back to this. Those decisions can sometimes be, "Is it okay to ship this next release with a bug, with this bug? We haven't fixed it, but you know, we really want to ship. Or is this bug a showstopper and we can't release it until this particular one is fixed? What we built, does it meet the requirements adequately enough to move forward or not?" You know, those sorts of decisions that are sort of tactical, but tied into important, larger overarching questions, up to the next level is sort of, "What should be in the next sprint? What's the next thing that we should work on?" And there you're at the level I think you were asking about, where things seem to happen very iteratively and without too much regard to the bigger picture, but just kind of down in a trench trying to polish a local maxima or run some tests or ship a feature or something like that. And those decisions also have to be made. Again, they can't be theoretical. Something's in the sprint or it's not, and either the last sprint went well, or it didn't, and stuff fell into this sprint from that. What I mean, you're dealing with a tangible reality all the time, and then the buck stops with that product manager. But those decisions again should be made with reference to, well, "What are our goals this quarter or in this time period? And why are we building this feature? And how many people will be affected by this bug? Is for those people, giving them a bad experience, an acceptable price to pay towards the larger goal?" So, there's a sense in which often the product manager is the person in the room who's supposed to be looking levels and levels above the current moment to figure out a decision. In some ways you'd say the UX person is doing that in a different sense: they're going out to like what people think or what we know from our users or they enlarge the question in a different way. But I think the product manager says, "Well, the company's strategy is this. And that's informed the product strategy, which I'm familiar with. Because either I'm the head of product and I own the roadmap or I'm on a well ordered product team and the head of product has communicated the roadmap and my portion of it to me well, and I have autonomy to execute my part of the roadmap." So, there are actually these tools and mechanisms that that ladder up and down from like the very biggest picture of the company's dreams and yearly goals and quarterly goals down to what should we ship? Now, like any of these kind of project management or information management processes, like a roadmap or a sprint planning process where you're relying on a person to kind of make all those times connections, it is vulnerable to becoming kind of just a thing on autopilot, where it's just all happening, but nobody is really saying, are we on track? What's the meaning of all of this? Does this add up to anything? And I'm not some sort of spotless paragon myself. I've found myself sometimes leading a product team, doing lots of things well and correctly, and still taking a step back at a certain point and saying, we're off track. We've gone off track, and enough of these yellow flags have now... Or funny feelings in my tummy have added up to the point that, you know, if we continue like this, we're not actually achieving our goal. And they're none of my official signals yet say that we're off track, but the fact that I did step out of the day-to-day and look at a different timescale or a larger question that we were supposed to be answering has woken me up. And there's this danger sometimes of getting too attached to these techniques and processes, but at best they do help things stay in a line. And if you have a healthy team and you're reporting up and down the line, and there's somebody with authority who is watching the biggest goals, I think there already are methods that can work, you know? But you have to assess the kind of health of that on any product team, how well they do that. I know you're more interested in the product management side than the IA side, but you could say sometimes a lack of that... That no one's written down a map. Like we talked about it, we have our OKRs, blah, blah, blah. But no one's really done that IA work of saying, "And this is what it's going to look like," or "This is the part where we're in, this part of the map now, and we're trying to get over here." And helping to kind of do that communication to everybody so everybody can agree on what the mission is. I think maybe that's like a lymphatic system that's missing, so that you've got a circulatory system, but somehow, it's not a healthy creature, you know?
Jorge: Yeah. As you were describing this up and down reporting structure and things like goals, it made me think of another book that I read last year, Measure What Matters, by John Doerr, which is about OKRs. And one of the things that I got from that book was that there are mechanisms to scale OKRs up and down the organization. And my sense is that the goal there is to make sure that everyone is pointing in the same direction. And I guess the concern that I have is at a different level of granularity, and you called it out; the information architecture per se. 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 Christian: Navigation within books or between books?
Jorge: More so within books. I recently upgraded to a... I had a very old Kindle device and I recently upgraded to a newer one. And the operating system has changed a lot between the two versions...
Christian: You're kind of... Okay, I'm going to sort of defend imaginary product people or UX people or tech leaders in companies like this. Some of this is a big company problem. You know, like big enough that you have teams that... The left hand doesn't know what the right hand is doing, or they have their own agendas. So, in theory, they're all the same experience. And there should be someone saying, "Hey, we have a fundamental experience and you can express it differently, but we all agree it has to XYZ in common." There are usually efforts to do that. And when I was doing the pattern library stuff, that was a version of that kind of thing. Nowadays, design systems are a version of that kind of thing, but often they're still about the interaction and not how it all fits together or how it works. But there are natural tensions. Teams are going to say, "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." It's non-trivial -- especially in a larger organization -- to just, you know... Everything's constantly shifting. It's a system. You could gradually maybe bring it into harmony, but I think you just have to have some tolerance, therefore. The consumer has every right to expect it to be perfect. But I, know, from being inside the sausage factory, how much that can almost never happen, especially in large organizations that have probably completely different orgs making those things, and maybe not enough cross team alignment. Every big organization I've ever been in is literally either in the process of becoming a little bit more decentralized or more centralized, or it's finished doing one of those things and it's about to start doing the other one. And they never find the perfect amount of decentralization and centralization for all these different overlapping things. So, you get matrix reporting. I have my boss, but I also have my practice leader. And then one day my practice leader is my main boss and I'm embedded in a team and we're a service bureau. And it's like, none of these models are right or wrong, but they produce software like that or experiences. And this has definitely been... And I'm sorry to rant like this, but this has been like a hobbyhorse for me for a long time, particularly when I started doing mobile and cloud type stuff, which was what I was calling holistic UX. Meaning that you don't do the UX of your Kindle on the Mac and you don't do your UX of your Kindle on the Kindle and your UX of the Kindle on the iOS, on the iPad or whatever. Kindle should have a UX, you know, 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. And yes, there will be compromises, but they should always be the sense that... But "should" is easy to say. When I was at AOL, I think, working for a fellow named Matte Scheinker, who taught me a lot about product, I remember telling him like, "There should be information architects, like that should still be a job." I was having that old argument, like, should that even be a job title? And I'm like, "Yeah, there's some people they should just do it." And he's like, "Well, how many? How many do you need? How many IAs does this company need?" And I was like, "Well, at least one." You know, and maybe it needs to be the chief IA or the one person who just sits there near the CEO or the CPO or whatever and is just making that big map on some level and communicating it. Yeah, I feel like that's lacking. But again, that sounds utopian to me. Nobody understands that they need that in some sense, or it's hard to prove that having that is going to help some team meet its quarterly goals. Jorge: I think it's pretty clear that that's what's going on. And in fairness to the Kindle teams, the individual apps in the different platforms are coherent internally. It's this... I think you put your finger on it, it's the talking between them that seems to be not happening as much.
Christian: But were you pointing out... Somebody online was recently pointing out that Kindle also gives you no way to organize your library. It's just a giant list of everything you either have downloaded or ever, unless you delete things, I guess. And there's no grouping, or if there is, it's hard to use. I'm not quite sure what the story is on that.
Jorge: Yeah, I remember that tweet, and I think it was around the ability to do so in the Kindle devices themselves. And the reason I remember that is, I actually posted in reply to that that I could easily see how that could be the case, because -- to your point earlier about the constraints in different form factors -- there was a generation of Kindle devices that didn't have keyboards, and you had to type by moving a cursor around with a four-way pointer thing, which made it really awkward. Right? So, you did not want to be editing a lot of texts, so it made a lot of sense in those to not have it. And perhaps the newer ones, which have touchscreens, don't have it either because it's an artifact from that time? I don't know.
Christian: I also think sometimes you get into the difference between power users and ordinary users. So, I've worked on software where we burned a lot of cycles at times thinking about how to make the switching between your two accounts' experience better, or the managing your multiple accounts. Until somebody looked at the data and saw that only 2% of the users have even the second account, let alone multiple. So, I hate to say it, but maybe the long tail of Kindle readers don't have more than one screenful of books or whatever, and investing in a great system for organizing your huge Kindle library just isn't going to satisfy big enough fraction of their user base. Jorge: Yeah, that makes sense. Folks have got to make choices, right? And at least my experience in working as a consultant with product organizations, there's always more to be done than there are resources and time to do it.
Christian: I think that goes back to like, what are the incentives? And you say, of course, Amazon doesn't have an incentive to focus on that problem. They've got so many other, you know... Or Kindle, or whatever sub-team you're talking about. But somebody out there could be making it so that ordinary people have a lens they can put in front of anything they're consuming and organize it for themselves. And that may take different forms and it could be a plugin or an add on, or it could be another app you use instead, or it can... There's a number of different ways to give people bookmarklets or things that put a little more power in their hands. And I think this is a longer-term agenda that I’ve always been fascinated in, which is like, "Where's the Excel for data or for information or for lists, multi-dimensional lists and nodal, you know, nodally-connected things?" There's a lot of tools out there, but there's not sort of like this universal structure that people start to learn as a literacy thing. So, I feel like people are overwhelmed by their information as soon as it becomes more than one list, or have has to be managed dynamically, or anything like that. I actually would say, to be honest, I think something like Airtable is the closest I've seen, not to endorse a product specifically, but when I've used that, I've thought this is giving people who aren't database architects the ability to create structured data with relationships in a very copacetic way. And so, I'm hopeful about that. But you know, to just kind of go off a little bit more on a tangent, I've had this side project, hobby horse of mine that I returned to whenever I get some free time, which fits that model of sort of ideally being something that you could put in front of any other list or any other, you know, like a to-do list or a project list or something like that, which I call "One Job." My shorthand for it is one job, like "you had one job." But the log line of it, and you can see this'll date to when I first had the idea, originally, I would describe it to people as "Tinder for tasks." You know, basically meaning that even... Personally, like I'll use Asana, I've used it as a project management tool in jobs, but I've used it for my own personal to dos kind of convenience. It's a nice kind of just sortable list, but with recurring things. But I still find psychologically that looking at any large group of things -- and this could be the backlog for the product that I'm planning the next sprint for or the accumulated ideas that have piled up in my road mapping tool, or my personal list of just, you know, household tasks I want to do -- that it's kind of anxiety-provoking to see anything you ever thought of and anything you might consider doing or, or might get to if you get to it. You know, if you do 10 things, do they, here's the 11th thing. Like, that's a lot to have on your screen in front of your face and trying to get your attention. And so, the original idea for this One Job thing was just that you have a stack. You know, essentially you can only see one thing and either that thing is the most important thing on your list, so just do it or, you know, swipe it away, put it to the bottom of the stack and look at the next thing. But eventually you should hit a thing where you're like, "Oh, I can call mom. I could do that now." Or, "No, I don't feel like calling mom." You know, whatever it is. And if you get all the way to the bottom of the list and you're back at the top, then you've got to start doing your psychological work. But more generally, I feel like, how can we be empowering end users rather than leaving it in the hands of the businesses to always give the information the exact way everybody wants it. You know, like, I think this has gone back and forth in the browser world. You know, in the early days it was like controlling your own layout and look, I want this type face, I want this backdrop. And eventually that kind of didn't work as it would break the magazine design of the website, you know? So that kind of fell by the wayside. But I think you get that more with people maybe wanting to have more control over their privacy or how their data is going to be used, and there's a market maybe to give people the tools that come between them and the mess kind of product and help them manage the relationship with it better.
Jorge: Yeah, I agree. There is a gap in the market. You've already pointed to Airtable, that's one that immediately came to mind as a possibility. Another one is perhaps Tinderbox, which we've highlighted in a previous episode of the show.
Christian: I've tried to use that, and I think for me... I have sort of like a law of personal information management systems or whatever, which is that you have to go all in. And no matter how good or bad the system is, they only work if you go all in. And if you partially commit, and continue to partially use other systems at the same time, then you don't get any of the relief that it's all in one place, and that you can stop worrying about it, and you'll have more and more and more systems to track and manage.
Jorge: Another product that that came to mind, I don't know if you've had a chance to play with it, is Notion.
Christian: Oh, you know, I've been reading about it a lot lately, and I've seen people promoting it, but I'm not quite familiar with how it works. Jorge: My sense is that -- and I have not used it extensively, I've kind of played around with it -- but from the videos and tutorials that I've read, it strikes me that it that Notion is to something like your notepad as Airtable is to Excel. Where in Airtable and Excel the primary information objects that you're dealing with are some kind of a table-based structure, Notion is much more freeform and more text-centric. But the principle seems to be fairly similar, where you enter information and allow the structure to emerge as you gather more of it and start tagging it on the fly. So, it's intriguing. I do think that there are gaps in the market for such tools.
Christian: Yeah. I see it kind of plays into the wiki paradigm too. I used to use a personal wiki, and for a long time, that was another great, infinitely malleable, networked thing. But again, I think these things work if you just commit to using them there's an expression in 12-step programs that is, it works if you work it. You know, physically like if you go all in and embrace the system, you can make almost any system work for yourself.
Jorge: That seems like a really good place on which to wrap our conversation. And I feel like we have much more to talk about, and perhaps we will at another occasion. But for now, Christian, where can folks follow up with you?
Christian: Well, you can always check out my personal website, which is mediajunkie.com. And if you're near Richmond, Virginia in February, I'm doing a workshop there, but this may not be out by then. I've got a series of videos coming out with UIE, with Jared Spool's website, in their all-you-can-learn library on product management for UX designers. So, people who are coming from a UX design background and want to understand product management better, may want to consider making career in product management or kind of a hybrid product design career, might find some value in those videos. I hope they do. If you have a chance to make it to the IA Conference in New Orleans, which is in April, I’ll be giving the closing plenary there. So, some of the things you and I have been talking about, and probably a couple of other things reflecting on social software, mental health, vulnerable populations, things like that, that relate to my recent work. I'll be talking about those things as well. And if you're in Australia, I'll be in Melbourne in late June, early July at a Web Directions Product, giving a keynote there. So that's probably a lot of ways to find me in the near future.
Jorge: Well, fantastic. I'll be in New Orleans at the IA Conference, so I look forward to seeing you and hearing your presentation.
Christian: Great. Can't wait to see it then.
Jorge: Thank you for being on the show.
Christian: You bet. Take care. Thanks for having me.