Announcer: 0:00

Note. This podcast does not discuss nor endorse the idea of discussing stupid ideas because we all know there are no stupid ideas. Hello, and welcome to discussing stupid. The podcast where we will tackle everything digitally stupid. From stupid users and the crazy things they do to stupid practices and the people who use them. We'll explore the stupid things we all do and maybe even come up with a few ideas on how to do things better. And now that I got your attention, let's start discussing stupid.

Virgil: 0:42

Hello, and welcome to the broadcast of the podcast. I'm Virgil Carroll, the owner and principal human solutions architect at imonkey, and your host for discussing stupid. Today's topic is one I've been very excited to do, and I've just been, trying to schedule with my friend, Kanwal, for a really long time. When you actually look back at my history, as a professional in this field, this is really one of the areas, information architecture user experience, that I've been doing for a really, really long time. And, Kanwal and I have known one another for a really long time and have shared a lot of similar experiences, especially in the Microsoft world when you start talking about SharePoint and Office 365, but some of these other areas. But this has been something that has become more and more important today, and that is how do we really create a consistent experience, for our end customers whether it would be internal people or external people when we're also dealing with the fact that a lot of times we're interacting with them across multiple, not only devices, but also applications and really everything in between. So this, podcast is really us discussing some of the challenges around that, how we can tackle those challenges, and some of the really bad habits that people have that we have to kinda tackle from that side. So I'm really excited for this episode, and I hope you enjoy it. Well, ,Kanwal welcome to the show, and I appreciate you joining me here. Why don't we start off by, introducing yourself and telling us a little bit about what you do in the world?

Kanwal: 2:24

Hey, man. Virgil, thank you so much. It's an honor opportunity to be a part of this, part of discussing stupid. I'm fortunate enough to be a CEO at 2Lead. 2Lead is a generous consulting company kind of focused on user experience around SharePoint and Office 365 and more broadly in the enterprise space and helping people and teams adopt technology. So that's, just a little bit in terms of the way I professionally today do, but maybe it's worthwhile to kinda share a little bit of my passion and and kinda where I stand. That'd be great. I think throughout my career, I've done a lot of a lot of stupid things from from, from from day 1, I would say. I've been part of that, quite a bit. I started my career early around the dotcom bus, so, I wasn't necessarily the smartest in the field. I wasn't able to land a development job, but I, started my career as a help desk agent. And everyday, connecting with, daily with users, everyday users and how they use technology. So I I learned very early on around how the non technologist, the general public, uses technology and the challenges they run into. And I think sometimes that gets a little bit lost in, how how you and I and others who are so open to technology and are are using the web and, application on a day to day basis have kind of gone past some of those challenges that

Virgil: 3:38

they're using. No. And and that's a great segue into kinda what I wanted to really focus on today. Because one of the interesting things, and I know you and I were talking about it not too long ago, and that was you know, we've kinda went the shift from a long time ago when when technology was really first coming in. There was there was all these different toolsets to do all these different things because, frankly, technology wasn't that mature, and so you needed a lot of different things. And so then the world kinda went into this process of saying, well, look. We can start building these super toolsets. And, you know, on on the website, a lot of them are content management systems internally. You have systems like what Oracle and Microsoft is on the SharePoint and all these things, where you could do a lot of different things in there.

Kanwal: 4:22

Mhmm.

Virgil: 4:22

But now, kinda stepping back, especially the last couple years, we've actually kinda shifted back. And and even if you look at a company like Microsoft in the way that they're offering Office 365, I mean, there's literally all these micro tools that you use to interconnect or even the way that you're working in, like, the space marketing and digital marketing. There's all these micro tools that you use to accomplish different things and different social channels and all these different things. And and it's kind of that challenge of getting to, well, how do we utilize all these tools to do the same job that we were using this bigger tool to attempt to do to then turn around and replace all the things a long time ago that didn't do anything really well? And I'm I'm sure you're seeing this in in your side that there's that how do we get all these tools to work together?

Kanwal: 5:16

I mean, that's a huge challenge. Right? It's it's hard now sometimes just getting users to use one tool, right, and trying to train them and help them adopt that. There's to your point of bigger challenges, once you get that tool adopted, there's a number of different tools, not just from the same vendor like Microsoft, but other, platforms as well that are working in different ways. How do you actually educate and train and and make sure that users aren't, kind of disjointed from that? That's that's become that's been a a really, really, really challenge, I think, for a lot of enterprises. I mean, you you know, with larger organizations, they've got different teams. So even though there's a development team for, as part of IT, different teams are working on, improving the different experiences or improving features for different, applications. And getting those team to to connect and talk or leverage the same baseline, that that's a challenge in itself. Absolutely. I think one of the, one of the ways that I've seen success, on on that was around, around the aspect of this guidelines, providing a framework, brand guidelines for for enterprises on how they should be using their brand across, and how it should get implemented across the board. So for example, top navigation, right, is a common one. How do you navigate for users? How do you navigate for one experience to another and how that navigation experience consists consistent. There's a few companies that have done a good job. I think Microsoft, in a lot of ways, has been, taking advantage of what their other what other SaaS products are doing, which is providing a consistent global experience, as part of their app launcher, as part of their Office 365 sweet bar. No matter what application you're in, you're gonna see that Office 365, sweet bar, which has which has saved a lot of, a lot of headache with, end users.

Virgil: 6:59

Yeah. It it definitely gotten better, especially since they stopped tampering with it for a while, which was kinda one of those things when they were changing it on a daily basis. But, yeah, I even think about it, like, you know and I hate to say it because, you know, you and I both own businesses, so we know that sometimes we we we try to eat our own dog food but don't always do it. But, you you know, when I when I go through the process of working with a customer, you you know, on a project, we have our project management system. We have our system where we do invoicing. We have our system where we do track our tasks. And then and then personally, I have my own to do system that just gives me the right kind of notifications on my phone so that I stay on top of my tasks to go against the projects, to go against the invoices. So it's all these different systems. And, you know, one of the things that I think is very challenging, you bring up that one thing Microsoft has done well, and I'll say well in the last couple of years because they kept kinda shifting this, but they've gotten better is Mhmm. Having a more standard nomenclature that they're using for the way they describe things. And that they've still got some issues where you can have a team site connected to a team inside of teams. You've still got some of those kind of challenges, but overall, you you've got a better consistency. And that's one of the challenges I think when you start going outside of a single ecosystem is this group kinda describes this one way, this group calls it another way, this group calls it another way. You know, there's a vendor that we work with on forms, and they call a form solution a dossier, which, you know, is a very German way of describing things. And it's just one of those things that you bring it. And so I think one of the challenges we have as kinda information architects and that kinda stuff is how do we kinda get around that and say, okay. They're gonna use different nomenclature. There's very few systems that actually allow us to make changes to the way they describe things. But what are some of the ways that you've worked with customers? You talked about your branding guidelines and kind of some standardization. But what other ways do you help them kinda get that into a more cohesive experience?

Kanwal: 9:12

Yeah. For sure. I think I think probably the I think the core message for me has always been is that around previous notion of iterative releases. Right? This notion of working with end users at the end of the day, providing them a release early on, training them on it, and watching how they use that, right, has been, so, profound as for shaping my career in terms of what I focused and shifted away from development to more user experience and strategy, digital strategy across the board. But it was getting early on feedback from users and how they're using the tools and then how to take that feedback back to the product owner or, as a product owner, how to incorporate that into the next release. That, for me, has been probably the biggest, biggest feedback or the biggest change. So the way that's worked for us, both, in my current company, in my personal life, how I work with customers, has been mapping out success across certain time period. Most cases, it's, you know, talking a little bit about the agile process here, but essentially defining a sprint, defining clear goals for a sprint or a release, and then working toward that and making sure you're you're mapping toward. Because I think, I mean, a lot of times, we try to create complex solutions for some sometimes a very simple user need. Right? And and that's probably the biggest thing that I found is working as as a as part of the agile process and just iterating through that.

Virgil: 10:33

Yeah. I can see that. When you go through those processes, you do things like do you do do journey mapping, or how do you kinda map out those processes, especially when it goes across different tool sets?

Kanwal: 10:45

Right. So every every engagement, and great question, every engagement needs to every process needs to start off with understanding the user. So first and foremost, you need to understand, do some interviews and connects with the actual users who are having challenges or you're building a solution for them. So really helpful to have an engaging 1 on 1 interview with them to get some insights, because all that feedback that they're sharing around their user needs, their wants that they have helps you define an overall persona, an overall, profile of what their needs are. And as you meet more and more users and as you interview more and more people, you get a really good kind of, understanding of the core needs that are happening across different departments, across different age groups, across different regions, and scenario level as well, within the organization. So understanding users is probably the most important part as part of the core of of what I've seen success with is to find that persona. And then there's, you know, a a handful of organizations that say, oh, great. Now this now that we've got this, what's next? Well, one of the next things you should be doing is actually, to your point earlier, virtual is mapping that that user's journey, that persona's journey across not just the application you're building, but how do they actually get to that application, and then what are the activities they're doing after they've left that application. So, you know, you were mentioning earlier that, hey. As a business owner, I've got my product management tool. I've got my invoicing tool. I've got my collaboration tools. Well, you're not gonna start your day off with all those tools at once. Right? You're probably gonna start off probably with your, product management tool, just trying to understand if there's any risks on the projects, issues on a project, and looking at, does something need my attention immediately? And, go and support the team on that. And then so part of your user journey is gonna be looking at probably the PMO, understanding if there's any challenges, do I need to connect with the team or customers. And then from there, moving on to to, after those blockers are kinda removed, actually doing some, some work or helping support from an operational perspective.

Virgil: 12:44

Yeah. It's funny you say that because I always think of when we probably once every 2 to 3 years go through a process where we kinda look at the tools that we currently use and kinda explore what's out there and see if there's something that meets a little better need. But one of my top priorities now has been, especially when you're in a brand new technology, is first looking at how easy is it for the turn off notifications. Because you can just get inundated as soon as you do that, and people start going all of a sudden, everybody gets crazy. And and that's it's funny because, you know, you you look from the salesperson perspective, and that's what they all go like. Look, you'll get an email notification whenever this is updated. You'll always know what's going on. And it's such a great practice until you actually have that happen. You're getting updates in multiple systems. I even, you know, in in playing around, I can remember when we used to use Slack, and we would integrate with other applications. And that application would send me an update, and Slack would send me an update. And then that application would send me an update, and Slack would send me an update. So I I I think you've got a really good point that it's very easy to get kind of overwhelmed with these things and to take more of that iterative approach to kind of thinking about how you can move into things slowly. So do you typically recommend to your customers that they do that on kind of a tool by tool basis, or do you do it more focused around, like, maybe you have 3 tools that need to be part of a process, but more moving into that process more slowly.

Kanwal: 14:10

Yeah. I think it's important to move towards that process. Very few organizations are ready to adapt an iterative model of, you know, typically, organizations just say, hey, TubeLead. We'd like to deliver this. Can you build this or customize an existing platform? And all they want is that outcome. You know, come back to us after 3 months. If you need to engage with their business, go for it. They don't they don't necessarily understand. So product sponsors generally don't get it. It's usually the the day to day, product leads or product managers that you work with trying to educate them from day 1 on how we are gonna run our process. It has no impact to necessarily you, but we're gonna provide you constant updates on, how we're progressing, whether we're achieving our week to week goals or biweekly goals, and then how are we how are we moving forward. You know, what's what's, next in the next 2, 2 week, sprint that's coming up. Yeah. I think I think it's important to not necessarily, and and this goes a long way with, you know, both on how how you wanna run a process, which is, you know, if you wanna run an iterative process and deliver features little by little to, like, a pilot set of users, that's great because you're getting early feedback. But at the same time, you don't wanna force that and do edited releases to a broader audience, maybe the whole organization. For example, you know, we were working on a on an application for, communication collaboration kind of synced to all the SharePoint and Skype for Business, Microsoft Teams tools into 1, there's a 180,000 users. And you can't necessarily deliver edited releases to a 180,000 users. So you gotta look at your scope in terms of the the waves of how you actually launch this, forward as well. So there needs to be obviously a little bit of planning around that.

Virgil: 15:46

Yeah. That that's so very true. What have you found, because I know this is inevitably, whenever I'm speaking out there on the circuit and I'm talking about these type of things, the number one question I always get is, you know, not only how do we convince management around this, which we hear all the time, but I think it even comes more down to, have you found that not necessarily that magic bullet, but that that one level of will that an organization has that has been key to actually this type of integration, bringing multiple tools, and kind of really wrapping your head around these processes, both internal, external. Is there a level of will that you've really found in an organization that is like that that sweet spot that if if they believe this much, then it has a better chance of success?

Kanwal: 16:36

No. I I think I knew the level of will is so hard to to get people to buy into because, you know, you gotta recognize any sort of change that you bring into an organization as an executive, as a product sponsor, you're some a lot of times putting your neck on the line, right, to say, hey. We're gonna transform everything within the organization, and we're gonna integrate all these applications together, and it's just gonna work. And that's obviously not not the case. So I obviously wouldn't recommend it from day 1, and it wouldn't recommend it for day 100. It needs to be a continuous process where you're getting people adopted. What I have seen work really well is that right off the bat, when you have that discussion with an executive, to build out that road map with them immediately. And the road map doesn't need to be necessarily you wanna start with a technology road map, like a a plane of what are all the different tools that you're using today, and then talk about the challenges they're having. And, oh, we just want help with Office 365, or we just want help with SharePoint and Teams. Okay. Great. What about all these other tool that people use? Let's not worry about those. I'm like, okay. You know what? It's good that we've got a technology landscape view of all the different applications you're using. Let's go ahead and, make sure we're focused on this goal. And then what we found is once we do the kickoff, immediately right after the team has gotten really good at as they see challenges or hints of integration or challenges where we're gonna need to connect with other teams, they start putting that on the road map saying, this is not gonna be delivered as part of this scope and this budget, right, because we're laser focused on the scope. But here are the other challenges that you're gonna have across the across the board or additional features that we think are gonna be beneficial because the problem just isn't for users that navigation and, let's say, Planner is difficult. It's because when they go from SharePoint to Planner or Planner to a group or group to Yammer, that the consistency

Virgil: 18:22

is different.

Kanwal: 18:23

Right? So, you know, you gotta be cautious of what you chew, take on, and you gotta be cautious of just starting small and making sure you have clear focus, but also introducing them to, like, a timeline based product road map. So technology landscape, start with that, right early on just so you have an understanding of and the and the executive has an understanding of all the different technology pieces, just a visual. And then you take the technology landscape and make it more timeline based to say, hey. For phase 1, this release, we're not gonna do anything but this. But next phase, we're gonna now start integrating maybe Salesforce and SharePoint together. Right? And, maybe you bring that connection in or Salesforce and CRM. Right? Or we're gonna stick with Salesforce when you're now you're gonna integrate with Oracle. Yeah.

Virgil: 19:04

I think in all the public websites I've done out there in the world, I I, a lot of times, preach to customers. It's not really about the willpower you have to launch day 1. It's really the willpower that you have to stay the course for more than 10 minutes because inevitably, you have all these different stakeholders that have different ideas. And, you know, even going through a good process, you may convince them that your way is better, but in the end, as as I'm sure you've seen this, as soon as we walk out, a lot of times those internal people start rearing their heads again and bringing back their old things. So I my number one encouragement is when you launch a new initiative is, you know, as much as possible, don't touch it for 6 months. That doesn't mean, you you know, you can't do some finessing or figure out you have a search application that you need to do some tuning on or something like that. But it's more that don't fundamentally change the direction you went until you actually have enough information to know that you need to make some type of greater shift that you went down there in that. So

Kanwal: 20:10

Yeah. So major releases and minor releases are, Virgil, a 100% agree. It's a big shift and a big need that's there. And usually for customers, we say, hey. This is minor release. It's not gonna include any enhancements. If anything, the minor release we're gonna do 6 months from now will be any bugs or little tweaks that we found along the way. No new features at all. It's definitely, much needed. I think I think just kinda going back to, you know, I was talking about the technology landscape and the road map. I think the important part also is that I think as consultants and as, you know, taking on a certain budget and scope and that risk involved in executing that on a certain timeline, we really detail out what each of those activities are. We know full well what needs to happen there. So we give customers all that insight around here. Here's I'm gonna build a public facing site. Here's I'm gonna go through IA. I'm gonna go through detailed design, and I'm gonna build it out, and we're gonna do QA, UAT, etcetera. We document that really deep detail. But anytime we see features or requests that we think are gonna be beneficial for that future major release, add it to our road map and assign them as the owner. Meaning, we're not taking this on. This is on you. We recommend you to take that on. At least they're aware of it that there are future releases that have come up, come into play. I think I think the moment you start doing that early on, I've seen that level of will all of a sudden is like, oh my god. We're not we're not just planning for day 1 or day 0 of launch. Right? Because the budget, everything's been planned for day 1. What are we doing day 2? What are we doing day 100? What are we actually gonna do after the fact? Are we actually gonna do anything? Like, do we have that support from Vergil and the team, once the site's launched and, if we have any future requests that come through? It's something they need to think about really early on.

Virgil: 21:44

Yeah. And I gotta tell you, actually, I think today that's even a bigger challenge because, you know, I I laugh. You know? You think back when especially when you and I first got involved in the SharePoint world, and we'd have these 3 year cycles of changes in that. And so you you you you'd have the 2007 version and 2010. You'd have these years in between where you could kind of adjust and figure out what to do, and then everybody would get upset. You know? Oh, god. Now this new feature is in there, and we can do this now and and that kind of stuff, and why couldn't we do that before? Now I think about it, and and not only individual platforms are changing every 5 minutes, but on top of that, everybody's using 25 different systems. And as soon as one gets out there, another one comes out with something better, and another one comes out with something better. And, you know, what have you kind of been encouraging customers? Do you do you tell them, you know, always continually look for that better way, or is is there kind of a middle ground there where finally we have to say, okay. Do we really need that?

Kanwal: 22:46

It's yeah. That's probably the biggest challenge. I think our careers have shifted from architects and developers and, like, building these perfect solutions that work really well, quote, unquote, for 3 years to shifting away from that where we're more focused. We're definitely doing that, but obviously on a smaller scale or more iterative scale. But our roles are now more as product managers. Right? So as a product manager, we're now building out the road maps. We're also incorporating the road map of what the platform, like Office 365 and other applications are delivering and saying, hey. This feature request that came through, like, we've had a customer recently come through and say, we wanna build a a notification dashboard for Teams notification that show up in SharePoint and SharePoint notification that show up in Teams. And they I think they came up with that last year, and we're like, awesome. Now why pay for it? It's already on the road map. And it might not be exactly how you want it. It's gonna get you 60 to 80% there. Right? Let's wait for that and then see if that meets the needs. And if it doesn't, then we can either custom build or find ways to tweak it. So I think and that's what one of the things that's really, helped out is just that focus on clarity in terms of what is possible on the platform today. Is it a is the request that you have, is it worthwhile to invest into now because it's just a short term need and you just gotta have it. You can't wait for Microsoft or the platform to cope with that, or or is this something that you really want, want immediately and and and, start investing into that where not exactly a 100% sure whether it's gonna be the kind of long term strategy. So I think I think in a lot of ways, we're shifting more and more to guiding and and clarifying and mapping out these releases and just making sure people are are clear of, kind of what's coming up.

Virgil: 24:29

Yeah. I was gonna say we just did a or we're I guess, we're still in the process, but we're working with one of our customers to look at a new content management system and kind of the same exact thing. I I don't think it's even about features that are coming out for a particular tool, but it's also what happens when you look at tool to tool. And, you know, I I know this will just surprise the heck out of you, but, you know, we we had one CMS and another CMS, and, of course, the salesperson for one CMS sends, you know, the customer a follow-up that rips apart the other one around these things like, look. Hey. We're we're graded up here by these guys, and these guys are graded over here by this, and, you know, and all these different things. And and, you know, they asked me to kinda come back and give my objective opinion, and I said, well, you know, where sometimes I'm not 100% sure. Yeah. This group has strengths in this, and this group has strengths in that. But I said, here's the fact. The maturity model of your organization means that you're not gonna hit being able to use that type of functionality really well until you grow as an organization, you grow as a staff, you grow as an understanding of how you really understand your digital customer. I said, so what are you talking? 3, 5 years down the road where you're just looking at doing that? So sometimes I think there's the other side of things change so much, not only inside tools, but including additional tools that it's so easy to skip and hop and jump and, you know, move because it's like, oh, well, I really wanted that feature over there, and that's really the thing that was gonna make it.

Kanwal: 25:59

Yeah.

Virgil: 25:59

It's just like you talked about the notifications. Yeah. That's cool. But I have a feeling when it comes down to actual practice, they probably won't find it quite as cool as they thought it was because yet it's another place that I have to go for another set of notifications from that. As a matter of fact, you know, the Microsoft side, it was the, the work management piece that attempted that, I think it was. Is that yeah. Yeah. I think so. Yeah. And the task management and and never went anywhere for a lot of people. So I think sometimes we get very much up on features and, like, oh, this is gonna change our world and everything like that. Yeah.

Kanwal: 26:33

Exactly.

Virgil: 26:34

Where it's go ahead.

Kanwal: 26:36

Let me think no. No. Sorry. I was just gonna say, absolutely right. I think I think the challenge is that people want these features and they want them now. It's like, I just gotta have it. And sometimes the worst is going up against a customer who's a product sponsor and has a a big check and says, here's the money. Let's go build it. And and you just gotta be very, to your point, very objective about these decisions on whether you wanna go down this path or not. I I think it's I think it's important also, with these decisions, Virgil, is around sharing the fact that the way to success is to fail fast. So if you do wanna spend a lot of money on this new feature, like notifications, and you're okay that this might break 6 months down the line given API changes or challenges or Microsoft can open its own approach and you're ready to fail fast, let's do it. Right? As long as you understand that this proof of concept, this approach might change, that conversation usually around failing fast has helped a lot in terms of having executives kinda rethink their approach and say, well, what what do you mean it's gonna fail fast? Well, this is this is what we've been sharing for so long. You know, let's assume end users adopt it and they love it. But what if the platform changes? Right? How do we how do we accommodate that? So and I think that's something that I just wanted to, like, really, really share is that if organizations, to your point from a maturity point of view, are not there, then you're not gonna have success.

Virgil: 27:52

And, again, I think another challenge that we kinda run into and, actually, I realized what a great topic of its own podcast would be talking about the true cost of costs of these things. And, otherwise, you know, back when everything was an enterprise software, you were spending, you know, tens and 100 of 1,000 of dollars purchasing some type piece of software. Now, somebody can run-in with their credit card and, you know, get something going in for for 5.99 a month for the the trial version or something like that. That it's just so much easier for people to pivot and change in that. And I think that's part of it is that they don't really stop and think through and really understand what they're doing and, you know, I mean, you hate to say it, but, you know, especially working in the digital world, you know, that I do on both the the the public website side and the internal, there are are 2 groups of people that they get probably more excited by shiny things than anything, and that is marketers and IT. And that the the the and they both have their own little equal sides of it. I I can't tell you the number of times. I've been at conferences and events where people are like, oh my god. This is gonna change our life. This is gonna make everything so much easier. And then 6 months, a year, 2 years down the road, they've done nothing with it because they frankly found that they didn't have the ability in that. Yeah. I think

Kanwal: 29:12

I think it's important for, like, the CIO, right, or whoever the decision maker is on enterprise IT strategy, is you've gotta have this model of bring BYOA. Right? Bring your own app. You've gotta have that strategy. You gotta encourage people to add in their credit card, trial it out, test it out for 3 months, 3 weeks, 6 weeks, whatever it might be. But you have to also define what are what are the, from a compliance or risk perspective, what are the key records that we need to maintain? So, you know, in our SharePoint space, it's always been, SharePoint is a document management system. Works great, but that's where the final place is gonna be for your your deliverables, your documentation that you wanna share at at the record. But if you wanna use other tools like Dropbox and Box, go right ahead. Use that short term. Don't stop people from adopting or trying those tools out for a short period if it makes it easier, for them in the short term, but make sure they understand what are the enterprise level standard that we have in place, for the applications. I think I think that's that's another important kinda call out as well. Fail fast for where the the, enterprise strategy has not been defined for applications and interfaces. Try different things out. And, if you do have enterprise standard, use that first. Try to adopt it.

Virgil: 30:21

So when you go through those processes, you you said fail fast. I'm kinda curious. Do you work with customers just on success strike criteria, or do you also kinda work with them on, okay. Now you're trying out these new tools working together or bringing a new tool into our system. Do do you also have failure criteria that you look at as well?

Kanwal: 30:42

That's great. Yeah. I mean, you have to. Right? Like, you have to first start with a baseline, obviously, of like, hey. If there are metrics around what we're trying to solve, right, if we're trying to say, hey. We wanna make it easier for people to search. We wanna make it easier for people to manage your tasks. How much time do they take today? You know, it's, let's say, a a minute a day. Well, is this is adopting, let's say, a planner or adopting Slack or other tools that they might use can improve task management? Let's trial that out and then get that user feedback to see if that time is shifted from 1 minute to 30 seconds. Or for 1 minute, after 6 weeks or 4 weeks of trying to fail fast, you've realized that actually time's gone up. And, actually, we preferred Outlook task management for now because it was personal tasks. But the from an enterprise point of view, Planner or other tools just didn't work, and here are the challenges that we face with it. So I I think it's I think it's, to your point, really important to map out kinda criteria on what's gonna be successful, what's not gonna be successful, but also revisit it back and say because sometimes, you know, I think the challenge is it's hard to measure, quote, happiness. Right? Smiles on on a person's face or more importantly, when people just stop thinking about the friction that existing application caused. Right? Sometimes it's hard to quantify that. It could be based on the number of the number of times they log in to the application. Maybe that's reduced or may might be the time they spent in the application that might have reduced. There's a lot of different metrics you can look at, but that there's also that, the qualitative, metrics that sometimes are hard to quantify, and you've gotta connect with users and and get feedback from them as well. Like, is this working or is this not working?

Virgil: 32:13

Yeah. You you just made me laugh because I I thought about I was at a usability conference a long time ago. Complete side note. But, somebody from Microsoft UX team came and talked about how they came a part of the decision on the the Windows Vista interface. And, that was both their their happiness index that they put together, that was corporate, and they also put electrodes on people and then would show them different interfaces and and and, would measure the the movement in their smile muscles as part of that. So, yeah, you you can definitely do that. But I mean I mean, what what you say is is so true and that we have such an issue of, you know, people trying to move down. And I even think about it, like, you know, one of the things that we realized internally was that the way that we quote out projects to customers and you have to have tasks associated. Those tasks are kind of these macro events. I mean, it's not like I sit there and say today, I'm going to I'm going to install the software, and tomorrow I'm gonna do this. You don't communicate that to the the customer. Those are your tasks that you do behind the scenes. And, you know, I'm sure you've seen the same. There is no project management system that does both sides well. Manage a budget and all that kind of stuff, plus and manage kind of the micro leads of us. So you end up using multiple systems, but I think we still have that fundamental challenge that we do that. They can get disconnected. They can get disconnected very easily, and, you know, you have a budget in 1 and a budget in the other, and now they're different. What do you do? And so what are some of the things that you work with customers when they're using these different things? You know, how do you not only just communicating to people and helping them understand how to use them, but but how do you keep that consistency going and kind of manage that from a governance standpoint?

Kanwal: 34:02

It's a challenge because the moment you bring in governance, there's both the systems and the policies in place that people need to follow, which, you know, human error leads to human error. People don't always follow it. And then there's also the aspect of processes around how people are leveraging those pieces of, IA that you want for others to incorporate as part of their decision making process. So that's really, really tough. I think, I'll give you two examples, and it's probably very similar for for you you as well and and for quite a few of the listeners is for a consulting company, a lot of what we do, everything centers around the product code, the sound number, right, the statement of work number. So we've got a 6 digit reference code that references it and all of our communication that happens both with the customers through email, as well as the task that we create within our product plans, to how we take meeting notes. Everything revolves and has a reference to that statement of, work number, and it tails around that. It allows us to at least not necessarily have full integration between systems from a technology point of view, but at least when different team members from, from the development team to the consulting team to the PMO team to the design team, they all know what product they're talking about. It's very, very clear. So that's helped us, tremendously. I'll give you an example of the customers, for example, in the in the legal industry. For them, one of the biggest, you know, pivot areas is, matter number. Right? Essentially very similar to an engagement, code or a statement of work code. Their matter number is what everything revolves around, their billing, how they spend their time, what communication they have. Everything is tracked based off of that. So even creation of SharePoint sites, creation of emails, all that tracking is based off of that. So I think I think the key and the trick for anyone who's looking at architecting this effectively is finding that core nonnegotiable across the company that everybody can understand. Usually, you gotta follow the money, so to speak. You gotta follow the money and say, is this what everybody is driven off? At the end of the day, no matter who you ask, they'll they'll reluctantly say yes. That's that that is our core, what we drive. Every every team understands this number. Great. Let's start with that. So in the SharePoint space, in the collaboration space, if that is not part of content types, that are not part of site creations, etcetera, There needs to be very clear decisions of why not, because one of the things you can run-in a enterprise platform like SharePoint is you can run, compliance reports and do, like, ediscovery, searches across that SAU number. Right? And that's really, really important to do. So I think for all the money, start with that, and that becomes your core enterprise level metadata that that I found. And then and then number 2 is you expand on that a little bit and look at now pivoting from that SAU number is, what kind of financial reports do you need? And, I think it's important to recognize that IA isn't always driven by, you know, the almighty dollar, but it helps understand a lot of the decisions that executives need to have, but also helps employees who are work doing the the work and the day to day reporting. They also understand how that reports up to the executive team and vice versa. They have a clear line of communication on what is affecting the bottom line.

Virgil: 37:11

No. I you know, and I think adding on top of that, the other side that kinda goes into that is when you identify those new needs, we have to be less hasty to add new components to meet those and and really have to go back and look at what it is. And it is kind of that thing. I mean, I I've told people from year for years in the SharePoint world where SharePoint doesn't do anything awesome, but it does everything that it was meant to do 80% well. And what you really have to determine is, do you need that absolutely awesome, or is 80% gonna be good enough? And for a lot of organizations, they think the absolute awesome is what they need, and then they use, like, 40%.

Kanwal: 37:49

Exactly. Exactly. Spot on. If they're not able to adopt that 40%, there's no point investing to the 80 or even a 100%. So to your point, you know, it's just like the, the new, Office apps experience both on mobile and desktop that Microsoft's going for in their modern experience, where they're reducing that number of actions in the ribbon. Right? They've slimmed that ribbon down completely and done a really good job of making you very minimal, and now they're just allowing users to kinda customize what's in the ribbon and giving you just core functionality that you need right upfront and making it super easy so that whether you go from your laptop to your, tablet to your phone, that experience is consistent. So I totally vouch for that, and it goes back to editor releases and being a product manager. Companies invest into, you know, the investment platform. The platform investment doesn't mean that you need to necessarily launch everything for day 1. All it means is you've invested into that product vision, and you're gonna be there for 2, 3, 5 years. Awesome. So let's focus on the next 3 to 6 months. Let's let's just leverage 40% of the features and make sure that adoption rate gets to 40%. Because there's no point investing, and only 5% of the business uses that application. You know what I mean? And that's really, really, I think core.

Virgil: 39:03

I do. Yeah. So if you know, I'm kinda wrapping up here. If you were to, give my listeners kind of, you know, one piece of advice as they're kinda looking down this path of of using a lot of different tools to try and accomplish their job, what what's the one thing that you think they should always be looking at first?

Kanwal: 39:24

Well, there's 3 three facets of how people use applications. Right? Navigation, search, and the actual content. So pick 1 and really excel at that. So if it's gonna be navigation, build a navigation experience that it works really well, not just for your application that you're building, but how does it connect to other enterprise applications so that, for users, that becomes a very seamless experience. If you're gonna invest inside of top navigation to search, it's just a better investment for you as a company on search, make sure search isn't just searching content within one application. Try to find, over time, editor releases where search starts searching for content across multiple applications. Kinda create the enterprise level search for yourselves and invest into products like that and and start getting there. And last but not least, content. If you're gonna focus on making content and being not just the king, but improving the content authoring experience, there's more content being stored in applications, then provide content authors the guidelines and the tools they need to make it really, really effective and and deliver that. So those are kind of the 3 areas that you need to focus on, and it needs to be over overseen by iterative releases, failing fast, learning, and just continuing to continuing to release new features out and improve.

Virgil: 40:37

Well, that is some good advice. So, Cam, well, thanks for joining me here, especially knowing that we're both sitting in our respective locations, you know, with a little bit of wind chill. I think you said negative 35, and we're at negative 40. So just at least happy that our Internet is not working, but thank you again for joining me and and really sharing the information. If people have follow ups or wanna learn more about what you're doing and that kind of stuff, can you let us know is are there ways that they can get in touch?

Kanwal: 41:05

Yeah. Absolutely. The name's pretty unique, Ken Wall Kippel. Go ahead and search for me on, Facebook, LinkedIn, Twitter. Fairly friendly in terms of reaching out and, connecting. Obviously, the best place would be on LinkedIn, so, find me on LinkedIn.

Virgil: 41:20

Alright. Well, thank you very much, Ken. Well, really appreciate you joining us.

Kanwal: 41:24

Thank you so much, Virgil. Appreciate it.

Virgil: 41:33

Well, I hope you enjoyed that episode. It was a really good one, and I think there's just so much around that topic. And honestly, Canwal and I could have talked for ever and ever going through all the different aspects. But overall, hopefully, you took away the point that you have to think about how you really communicate, how you really architect your information across all these different channels, and how you really try and create that consistent experience with it. So speaking of that, we're coming into the part of, the kind of the end of my podcast where I talk about a buzzword that I feel like has kind of been overused. I call it the stupid buzz in that. And so one of the things that really irks me about buzzwords is when you have a buzzword really that takes a word that has some meaning and you add something to it, to kind of emphasize something new and then start overusing that across the board. And one of the words that have been overused a ton is this word called seamlessness in that. And so, years ago and and for a long time we talked about the seamless customer experience, which we discussed in our podcast today. But now the word, the ending mass has come on to that to try and take some type of new meaning that if a seamless experience is that you get a consistent experience across from, one application whether you're on a mobile device and then going on to, your computer that that that feels very consistent. Seamlessness means you should be able to start something here and end something over here. Why people think that that has some kind of different context versus a seamless? Because in a seamless experience, you should really be able to start something in one platform and end it in another platform. Why we think that adding nest to that makes some type of significance. But overall, it's not even really the irking of the word as much as it is that as soon as this gets into the especially in the marketing vernacular, we start to use this word over and over and go crazy. And every article I read, all of a sudden, nothing is seamless. It's all seamlessness. And somehow that's supposed to be more significant, and that's one of the things that really gets me about the whole world of marketing buzzwords in the first place is we bring these words in, and we just kind of overuse them and use them in all kinds of different context that don't make sense. So thank you again for visiting my podcast. If you enjoyed the show, I hope you'll subscribe. You can subscribe through Apple Itunes, Google Play. You can go to our website and view it. There's a lot of different ways for you to get involved. If you have any questions or comments on this episode, you can definitely reach out to me. You can reach out to me at my website at discussing stupid.com, or you could also hit me up on Twitter at at discuss stupid. That's not at discussing stupid, it's at discuss stupid in that. So until next time we get a chance to, why don't you go back and talk stupid on your

Kanwal: 44:45

own?