So many tools to choose from! So many messages from so many vendors. Everyone saying they are the right one! One size does not fit all and one solution is not right for everyone! How could it?! How do you find the right one for you?
You need to be able to evaluate tools from a balanced, objective point of view.
In this session, Liz Fraley will share strategies, benchmarks, and questions that she’s used (and seen used) over the years, so you will have something in your back pocket to help you choose the tool that’s best for you, your company, and your situation.
The truth is, no one really knows how to go through the tool selection process. They don’t always know where the biases or holes are or what to ask to find the hidden motivations. And the first thing everyone does is post a variant of this question on a mailing list, group, or in an email: “What is the best…” That question is great for retail products, but not so great when you’re looking at complex products that have a lot of moving parts, require teams to implement and enterprise support to purchase.
People always ask, “Liz, how do I choose?” She’s helped teams choose tools for small companies, big companies, and been on selection committees at giant global enterprises. There’s no one answer that’s the right answer for everyone. It depends on staff, resources, skills, and even company culture.
NOTE: Liz doesn’t mention any products in this presentation. This is the inside scoop about how sales works, how to work with them, and what you need to know to deploy/purchase something that requires more than just you to do.
TC Dojo Expert-In-Residence
Liz Fraley, Single-Sourcing Solutions, is a serial entrepreneur. She’s founded two companies, sits on the boards of three non-profits, and is constantly coming up with new ways to share knowledge in the technical communications and content industries. She has worked in high-tech and government sectors, at companies of all different sizes (from startups to huge enterprises). She advocates approaches that directly improve organizational efficiency, productivity, and interoperability. If you ask her, she’ll say she’s happiest when those around her are successful.
Watch the Video
Recorded: October 2015
Transcript (Expand to View)
[00:00:02.310] - Liz Fraley
Welcome to TC Dojo, you choose the topics and we find the experts. I'm Liz Fraley and this morning I'm your TC Dojo master. I've bought or been part of the committee to buy a lot of tools over the years for organizations of all sizes. I've helped them figure out what to buy, how to write up their RLI and see their implementations through. I've also had the opportunity to sit on the other side of the table with that dreaded sales team, and I'm here to share the inside scoop about how all that works. I've seen groups succeed and fail and helped more than a few recover from bad choices and after having been around a long time, I can tell you why the failures failed and why the successes succeeded. So sit back, listen, and let's get started.
[00:00:45.340] - Liz Fraley
First things first, when we're talking about tools, we're talking about complex products, so we're not talking about buying a tablet or an iPhone or some retail product at the store that you can just find. We're talking about big processes and I'm going to ask if anybody in the audience already knows about whether they have a defined process for how you go about evaluating and choosing your enterprise tool. Does anybody have defined processes and steps--rigorous steps they go through? Now, I'm not talking about going into AP and asking for your purchase order. I'm talking about start to finish. Here's what I want to buy, here's how I want to buy it. Here's what I have to do in order to justify it. Anybody at all? I'll give it a minute to see if you have questions, type it in. Usually, though, I see one of two things in companies is either the fait accompli or the simple selection process. Occasionally you'll see somebody has a little more process, but those are people who have learned the hard way and are really doing the work to make sure they get the right things. So what's the fait accompli? It looks kind of like this, someone generally arrives with news about a new tool you're going to use, all of these have happened to me personally. I want outlook the actual thing that they wanted was calendaring, although outlook does have calendaring saying I want outlook is not exactly what you're after. The third bullet down, we just acquired a new company that has interwoven. Meet your new CMS. Also a true story, we'd spend a year and a half trying to find out a real requirements for something and then there was an acquisition and our work was over. Not to say that it worked well or worked sufficiently or was adopted company wide, but sometimes that happens.
[00:02:43.570] - Liz Fraley
My favorite, though, is this last one at the end we're doing DITA and I want you to take this XSLFO class. What one requires of the other I can't really say you can do data without doing XSLFO, I'm not sure why that requirement is how it should be right, so there's a lot of assumptions in the fait accompli and it's one of those things you need to worry about and watch for the other--the opposite side of the coin, really that we always see is this sort of simple selection process you do a little bit of research, you contact sales for a demo, maybe you play with it hands on and then you compare pricing. This process works fine for retail. Which monitor do I buy? Do I buy an iPad or an Android tablet, right, things that we're pricing really is the difference, where you can actually look at research and know without a doubt it is anything's capabilities and total lifespan and everything you need to know about it with big enterprise products. This is not so simple and this will guaranteed to fail you. So the problem with both of those processes is neither one of them is talking about requirements, both processes, if we look again at the simple selection process, we're looking for information from other people to make the decision for our needs. We haven't spoken to them about their needs. We haven't really looked at our own requirements. right, and that's great for retail again but it's hard for something that's complex or something that's not a commodity, right, the simple process rarely works well for things that are not commodity or purchases for things that are complex products, because not all products fit all situations, whether it's all companies, all industries, whatever it is, not everyone is the same. I've got to--so here's the definition of a complex product and I'm going to tell a little story. Complex products are more than retail because they have these kinds of unique characteristics. They require implementation help so you don't just turn it on and it works right, think about SAP, think about content management for the enterprise think about those kinds of big systems, right. This is not a small turn it on and it works you usually need consultants or you need software sales engineers help. You often need new skill development by the people who are implementing it, whether it's the users or the IT teams putting it together, or they also can require negotiation with other entities inside your organization.
[00:05:38.960] - Liz Fraley
There's only one bucket of money for the company and if somebody else is competing with you for that bucket, you've got to negotiate with them to find out whether you're going to have all that you need to make your thing happen and a complex product require typically big budgets. This is not a couple hundred dollars or if you're out a couple hundred dollars because the tool didn't work, you're OK, these are big things, you compete for resources, you're competing for skills. There's a lot of moving pieces and the one thing that's most important to recognize when you're doing the fait accompli or the simple selection process, you're depending on outside reviews for complex products that can be difficult to gauge. The quality of a product can be difficult to determine from a review for example. I've seen a lot of posts on LinkedIn where somebody says, oh, I hate this product, blah, blah, blah, and you can't tell necessarily whether it was because the product is not implemented correctly to do that, whatever function it is they're looking for, whether it never got implemented or was implemented poorly or incorrectly, was never communicated it doesn't exist, it's hard to know whether a consultant failed, whether their team failed, whether the machine's not powerful enough to run whatever feature it is. Right. And the person making the review may not know. The problem is when you treat a complex purchase like it's a simple purchase, you are guaranteed to meet big requirements and you're--this will absolutely determine the success or failure of your implementation. So I got five minutes we're going to talk about each one, this comes up all the time when you're talking with people or you're buying big product purchases, there is no best tool.
[00:07:37.570] - Liz Fraley
You see this question all the time, all over the Web. What's the best CM's? What's the best source control? What's the best this? What's the best documentation product? What's the best publishing engine? What's the best social media outlet? What's the best this--if there is no best, every--not every tool is right for every company or every industry or every situation. True story, what works for Juniper does not necessarily work for Cisco. There is in some parts of both companies a cultural bias against the other and you'll see sales people talk about this, you know, in when--they're together talking just as professionals, you know, if Juniper does something, Cisco won't do it for the mere fact that Juniper did right, there's no requirement there. There's no it's a cultural part and that's actually a cultural requirement, and if you're not thinking about things like that, it doesn't--your tools would not succeed. What works for HP doesn't necessarily work for their OEM and what works for Big Schneider Electric doesn't necessarily work for a startup with only one or two writers. You're talking difference of scale, difference of support, difference of skillset, difference of budget right, It's not all going to be the same, even if the little startup works with Schnieder.
[00:08:48.790] - Liz Fraley
You're not necessarily going to get the same results or have the same success rate, if you implement the same tools, you need to know what your reality is and you need to pick a tool that will guarantee your success. Too often I see slacker questions from people who are trying to get out of doing this amount of work. Here are some questions taken from LinkedIn just recently or some I've seen--I see variants of this almost every day a fair one here is results are in, here's the list of top tools according to who, for what and in what situation? And did that reviewer who's posting these results post their biases and whether or not they were compensated for including a tool in the review and or left out ones that they weren't compensated for or were not partners with? It's very rare to see people who are posting reviews list their biases or people who are posting authority, points of view, top tools, best tools, those kinds of lists, it is very rare to see them posting where their bread and butter comes from and who was allowed to be included and who is excluded right, so there's that other one, got a great one here. What's the best management structure to manage your content? Are you a medical device company or a hardware company? Do you have regulatory requirements? Do you--are you a legal company or are you doing financial publishing? Is it going to matter where that content comes from? That's that question, prophecies or certainly assumes you're a software company and maybe you're that person is in negotiation with the software engineers to try and not have to use their software tool that the engineers are using. It's hard to say and it's not--there's no way to dig into that question, you could, but it's going to cost both the people who are answering those questions on LinkedIn and the person who's writing up that question to do some work and neither one is going to unless their sales team, and that's what their job is. Here's a great one, how do I go about converting framework to XML? Are there scripts available? Can you give me some pointers? I've been a violator of that one myself, I have to say. But there are entire companies who do this for a living. If it's a company thing, if there's something that there's hundreds of people at multiple companies working to do, it's probably not something you can script and get out of. I understand the instinct, but that's one of those things to pay attention to and the assumptions that go behind it. A lot of times you'll see these kinds of questions, especially from it folks, and that's partly a way for them to secure what they do and who they are and what their job function is.
[00:11:42.100] - Liz Fraley
They can develop a whole company within your company dedicated to building, supporting and developing tools, right, that's not what your company's job is your company is not a free market XML conversion company. right, your company is whatever it is that your product is. Allowing that to happen can be a can be a real problem and certainly be a time and money sink and get you in trouble farther down the road. So with number 2, product cost is total cost. I can do it with zero cost if I use open tools, well, I'm not sure where you get for free labor and copious amounts of spare time, but I would really like to for me time plus effort is not zero cost and when you're doing this kind of work, don't forget about the long term maintenance. If you build a tool that is compliant with DITA 1.1, as soon as DITA 1.2 out, you've got to update your entire toolset and you've got to do all that development yourself. What if there are bugs that somebody finds because you didn't work to every case? Well, that you've got to do all of that you're really building a company inside a company when you're doing this.
[00:12:54.580] - Liz Fraley
If you are going to use any open open source tool, you should absolutely make sure you have somebody from your company who develops that tool for that open source community, right, if you're putting a tool from the open source community in to your critical path in your company, you better have someone developing on it and being a part of that, contributing back to the community, all the code that they're finding and figuring out. Otherwise, you are at risk of not having your bugs fixed because that--other people don't care about that bug but you do. So it's not--total cost--product are not the same thing they work in different buckets, but that's not how it works. This slide from clavichord in 2010, Sara O'Keefe from Scriptorium said the average did it implementation is a hundred and six thousand dollars, that's not free--and that's assuming use of the development toolkit. As a matter of fact, they work in it almost exclusively. So you're talking about the cost of time and effort being a hundred and six thousand dollars.
[00:14:05.040] - Liz Fraley
Again, it's not free, is not necessarily--product cost is not zero cost. This is one of my other favorite myths, the pilot will tell me, think about if you're remodeling your kitchen, do you really have three or five contractors come in sequentially, remodel your kitchen, let you try it out for a while, and then they rip it out in the next one comes in and they totally do the information and you try it out for a while like you're having them try out five different kitchens in a row right, One, are they ever going to do that? Absolutely not and two, you spend a year without a kitchen and you have very little return to show for it. When you're doing a pilot, right, if you're really, really doing a pilot--so that you can understand what you're testing and what your goals are, then you're going to do more than just get a little tiny taste of it. Too often, I find that pilots are an excuse for hands on freeplay, as if you get your hands on it, you'll suddenly know whether it's the right thing for you.
[00:15:14.850] - Liz Fraley
You don't set goals, you don't set test, you don't set user acceptance testing, you don't lay out profiles and use cases and user personas in order to do the test of the pilot. That's almost never done, people do a partial or almost full implementation in order to play with software and call it a pilot and really, if you've done that much work and put that much money and effort into it, are you really going to take it and throw it out at the end of the day? Probably not. Certainly not, if it's a half a million dollars that you spent getting this done in six months. Very likely not to toss out your pilot, you've already bought the cow, essentially and I want to make a statement that, you know, pilot is not the same as phased implementation phase implementation, very, very smart, do a little bit at a time, grow your footprint, grow the features, grow the experience absolutely a good way to go but really, if you're in the middle of a phased implementation and you think of the pilot as the first phase, then it really is the first phase. You're not a pilot. It's not a test, not in any way, so if you're thinking a pilot is a test that will tell you something, you're kind of missing what's really going on.
[00:16:37.820] - Liz Fraley
Number 4 we talked about it a little bit already, the reviews will reveal with a complex product, there are a lot of moving pieces, a lot of contributors to success or failure, you've got to watch for reviews where misunderstood requirements or a bad implementation is reported as a total failure. How do you know what part really lead to success or failure? It is very rare for review to have that kind of information included for example, there's a presentation I saw at the STC summit this year and the earlier there is a updated presentation, actually, sEDX
he'd done the first version of it a year before, and she did a review that was amazingly well crafted. It was more of a scorecard. It listed all of the phases and all of the things that had to get done. It listed each consultant group separately and it showed how each one did based on different requirements in different phases. It was actually really fascinating. The the things she discovered, though, certainly after after she and I had our presentation sort of opposite, they picked a tool first and then decided to to do this.
This review never did the requirements in the first part. So and for them, early analysis didn't form later stages because every every phase was done by a different consultant, a different software team, a different group, and they weren't passing information along.
So that's one of those things you've got to recognize as a potential problem for Wyattville succeeds or fails. And a lot of people won't talk about those things because it's not either one, not something they see or have or were exposed to in the implementation. And it's just, hey, this doesn't work. Years ago, I would get complaints from the writers that might the tool I was supporting didn't work. And I'd say, what do you mean it doesn't work?
And it would turn out that they had not mapped the drive to the server. So it wasn't that the rule wasn't working. They'd skipped a step mapping the drive. So the course the tool can't open the file on the server because they were not map to the server. It wasn't the tools fault. It was a process problem. Right. And something else I had to address in a different way.
So you really have to understand and you really have to be careful and wary of reviews that recommend tools or slam tools when they don't have a very detailed scorecard detailing why you failed, what failed and how it did and what all the pieces are. The other thing to remember is a lot of reviewers have agendas of their own. Some will only review or recommend tools from vendors they have part partnerships or relationships with. And actually, one of the big players in the tech space.
Absolutely is this.
They only talk about tools for whom they have partner relationships and they do not declare those partner relationships and they will not talk about someone if they are not compensated for that.
So be very careful about your reviews and any of those best of lists. Because that stuff's just not there, there's very little transparency from compensation point for a lot of reviewers. OK, so here's the last one. And I know this is hard for a lot of people to accept, actually, but having been on both sides of the table and having learned this lesson many times over, sales really is not the enemy. We're not talking about going to a car dealership where they're playing games with you.
If you're buying complex software products, for example, those sales reps want you to succeed as much as you do. They really do not want to have a bad customer. Sales guys are. Tasked with finding the money that keeps their company in existence, if they pick a bad customer, if you're a bad fit for them there, it's easy for them to have sunk their company. Right. So they neither neither one of you wants to waste time or money.
And both of you are concerned that the product that they sell is a good fit for you. Right. Because they want a good customer, is a good fit for their company. And you want a good product that's good fit for your company. Right. So you got to understand and actually work with your sales rep and think of them more as a partner than as the enemy, especially for this kind of thing, this kind of purchase. Remember, it's not your job to be an expert in their product.
It's their job to be an expert in the kind of product they sell, not just their own product, but the class of products. Right.
You should ask them questions like, how do you know, success or failure? What are the typical factors that make one or the other happen? Right. And they will know that stuff.
They'll do interviews with you do walk through and requirements gathering to find out whether those success or failure factors are in your company so that you will succeed or fail.
Right. They really they really don't want a bad fit. They'll know what long term recession resources are necessary for success and they'll know what interdependencies need to be taken into account.
Right. So use them. They can be your partner. Way back. I learned this from a customer when I was sitting on the other side of the desk and she came in and said, hey, here's my budget.
Here's how I'm going to have to go through. Here's the timeline I'm looking at. Here are my requirements.
Do we fit? You know, can you meet this or is this realistic for your product, even for us to start to consider? And sometimes the answer is yes, and sometimes the answer is no. I used to ask my sales guy, go back to this slide here. It's a yes. Sometimes no is the second best answer. And he said no, sometimes no is the best answer because, you know, it's not a fit. Perfectly OK.
And when I gave this presentation actually to the CDC in San Francisco, I got an email about a week later from someone who said, oh, my God, I did exactly what you said with the sales team that was talking to me. And she said, no, my product is not right for you. Go to these people. That's the right product for you.
She was happy. The salesperson was happy. No more time wasted, no animosity between the individuals involved, and it worked out for everybody's benefit.
So really, if you think of sales as the enemy, you're only shooting your own self in the foot a little bit. But they can be there. They can be a partner for you because they are just as concerned as you are that their product is a good fit for you.
How do you deal with sales or how do you how do you do some of this investigation so you can find your requirements? There's a couple of ways you can do this. One, you can enlist a consultant for help. Sure. Right. They do this kind of thing for a living. They specialize in a complex product. So you can find a CM's consultant who deals with CM's vendors and CM's products and has seen a lot of different industries.
And they can. Then if you're paying them, they're in your sights, you might feel a little better because they're on your side and you might not hire them to do the investigation for you, that's just as bad. But you might have them help sit in on your calls with you and tell you what they hear and what they know and add to your team. So you may only needed a couple of hours of their time. Right. But it can help you add the expertise to your team that you might not otherwise have.
They typically have more reach and more experience with a wider variety of products of this type that you're looking for. Make sure you ask them, though, where are their biases and who are their partners? Absolutely critical. You can also go to your IT staff, right, it buys implements, migrates and maintains big products all the time, every day. That is what their job is. Right. But they are not going to do your requirements gathering for you.
They do not know what your requirements are, what makes or breaks a product for you, right? It will.
Do you expect you do that part and they will expect you to do it with the same diligence and detail that they would do it for their requirements? Right, and sometimes that's a that's a level of detail that a lot of us won't go to, but it won't do it for you. They will certainly sit in on meetings with vendors for you and say, OK, you know, this means this this means that they can help you in the same way that a consultant can because they've got they know how to deal with the big things.
Right. But you've got to do your job. They're not going to do it for you.
And they're going to expect that you will have the same rigour that they do so they can help you part of the way. But it's not a substitute for sure. Here's a great big story from Jamaine at Athame. He went through this process very recently. He was trying to get an enterprise content management system. And at the end of the day, when they got to the end of the project, he was. Amazed that they hadn't gotten the best result they they expected, and it was because they did a lot of these things that you shouldn't do.
He said we should have spent more time planning before hopping into vendor roulette.
Right. Spend more time thinking about the best first project, not the whole thing. Right. And if you don't have expertise, find someone, an independent, somebody who can help you with strategy and definition so that you can focus on getting your strategy right, not the technology tools are not the are not the make or break of your project. Right, tools are just a part of it. You have to be able to answer this question before you buy anything.
What is the irrefutable reason you will buy a specific product from a specific vendor within a specified time frame? This is the question the sales team wants to answer to on their side, that you need to be able to answer this.
If you can't answer this, you have no business buying anything, right? Irrefutable reason means you get the money corporate from corporate rather than somebody else that no one can disagree with you. You have given them a true, valid reason that says you are the priority. Right. And you know absolutely why this is the right product. You've done your investigation. You've done your requirements as much match up as possible. And the road map is good and this vendor is the right one because they do the supporta, they don't do the support or they have an API or they have sales teams or they have trainers or for whatever reason, and you know that you'll buy it by the end of the year.
So you have staff and resources and time on your side so that, you know, not only will you purchase it, but you'll be able to implement it and start using it in a in a timely manner. Right. And so you can show that you there was a reason for you to get your money. There's a reason to get it implemented.
And you're going to meet those those requirements. You're going to meet those promises. Right. How do you answer that? You have to do requirements analysis. You need to know the reality of your situation, your company, your needs, and not someone else's. So you can't post that question to the Web and say, hey, what's the best tool for me? They don't know you.
They can't answer it for you. You have to know from your organizational perspective what it's going to take to be successful. That simple selection process. There was no requirements gathering, not anywhere in that list. Right. But and it's more than simple requirements that we're talking about.
We're talking about management style. We're talking about deliverables, resources at your disposal time frame to deliver. Because really what happens if you don't make it? If we're talking about half a million dollars or a quarter of a million dollars or in some cases even one hundred thousand, what happens if it doesn't happen? As a story, my husband and I have been sharing a car for 15 years. Recently we moved into a new neighborhood and things are not as accessible as they were before.
And we've been discussing about buying a second car. We've been discussing this for two years, working out our requirements. How do I need it? What is it for? Sometimes he can bike to work, so I actually will have the car so he doesn't have it every day. At one point he could run to the office. Right.
So we're really do I want it does it have to be fully electric? Can it be gas? What what does the requirements? What car is the right one? And it'll just come out if I do it correctly, if I really look at all the requirements, I'll get the right thing. And I won't have spent money earlier than I need to be. I won't have spent more than I need to spend and I won't have the extra costs. I could have been paying insurance and paying off a car for two years.
That wasn't the right car.
So it's just one of those things to think about, if you look at it, this is a story that gets told over and over. Catherine Limón from NetApp did this presentation in 2010, and she had this same problem. She had not gotten everybody in the company on her side. She had sold it up and down. Her CEO knew exactly what she needed. She could answer that, a central question all the way up to the CEO, but she didn't answer that question with the other people.
And she had built them into her, into her into her argument and into her.
Why you got to really have people who are working together and working with you.
You can read Rebecca Anderson's paper from the STC annual proceedings. This is also she's a professor at the University of California, Davis.
She found that 10 percent of a project's success is the tools. So we're spending all this time talking about tools and we've got to buy the right tool. And I need a content management system. Why do you need a content management system? The success or failure of your department isn't going to be whether or not you have the right content management system, that's whether you've got it implemented and the people are using it and the workflows are there and everything else is in place.
Processes are just as important. And those are part of your requirements, especially in the beginning and over the implementation period. Where do you go, it's OK to ask other people what kind of questions they ask and how they go about asking questions, but you cannot use someone else's requirements for your business case or for your requirements because not every question applies to you. Go out and find the people, anybody you can get to. You're going to have to do a discovery phase and your consultants are sales reps that you hire in.
You're not going to get out of discovery phase with them. They're going to still have to do it because they're coming in cold. They need to understand you, but you also need to understand yourself. And if you do enough of this discovery, if you talk to everybody who's a touchpoint for you, you're right itself in your tool choice will be obvious. You'll be able to answer that essential question. Right, so what kinds of things do you need to discover organizational interdependencies, impact Steve staff capability, long and short term plays company culture.
That's a that's one that gets missed a lot of the time we were doing we were an early contender for Hitachi here in the Bay Area and for our product.
It takes a little bit of risk. It's more complex. It's more automated. There's a lot there's a lot more to it than very simple content management and automated authoring products. But their culture does not value risk. They are extremely risk averse and they will not take a risk and do a product that doesn't fit that culture. We were a bad fit for them. We wouldn't have been they would have been a bad customer for us. Finding out that can actually include our exclusion.
Your two choices. You need to make sure that you know what the competing projects are in your organization. Who else wants that budget staff time and other things that you want? And who and what deliverables do you also have to deliver even while you're doing this right?
So you need to really think about all of these requirements and all the intersection points. If you want to go down the open toolkit road, do you have staff that is interested in becoming a programmer? They want to learn, Excel and EFO. If you don't, you're going to need to hire one and you're going to need headcount for one.
So you need to think about all of these things because if they're career goals aren't wanting to be programmers, no amount of pushing them into doing it is going to make it happen. They'll drag their feet, they'll sabotage and it will just in the end, not work out very well.
So here's a couple of questions from my own stash. I have hundreds of questions. I sit down and I talk to people. I tell stories. We'd love to hear yours. But I've got a couple of questions for various groups. But because we're recording this and posting it to YouTube, I am absolutely not going to publish my list. But these are good starting points, right?
So I'll sit down and I'll say, hey, you know, people who are writing content, whatever group they're in and they're talking to the subject matter experts, they're capturing information somewhere and they're keeping track of it. Where is that? Are they writing it in notebooks? Are they keeping those sticky tabs?
Do they have a pad of paper or writing it in notepad? Are they writing in a spreadsheet? Where is it? How does it because you want to start getting an idea of who everybody talks to, what all the the talking points are, where all the intersection points are. Right. And these kinds of questions can start you down the road for discovering who else you maybe need to talk to sales.
One of the good ones for them is are they rebranding information? Are they Oeming? Their dogs are doing their products. Where, where, how? What does success mean to sales for them to support you in your product?
Is there anything where whatever it is you're trying to implement? Does it have any effect on sales or their operations or their sales team and if it does, what is success mean to them so that they throw their support behind you and you get the to do your project instead of someone else doing theirs?
Right. And this is really what we're talking about when we say talk to the intersection points. You want to know from operations. Do they do they have to ship docks or can they ship them later? Is there delays between international and US based order fulfillment? Do they do custom products? For the support guys, what happens when errors are found? What's the process that happens there? How does it get put back in, resolved and fixed and published back out?
Right. Then there's the standard pub questions, things like, do you have double page spread? Do you have illustrations that you have? Do you have foldout pages, do you have a regular form or do you just let everybody do whatever they want?
Do you explode your diagrams for it? What current technology skill sets do they already have? If you're looking at a product that has that doesn't have skill sets that they already have, then you're going to need resources and money to cover those those deficiencies.
So that's one of those things. So here's like a set of questions. Use them as a starting point to start asking more questions. There is this is in no way enough questions and no way that these will answer everything you need. And I don't ask all of these questions of every company because some companies that don't rebrand don't need those questions at all. Companies that don't publish magazines, for example. I'm not going to ask them how thin is your paper?
Because if you've got a thick black out on one side, a very thin paper, you need a thick black ad on the other side of that thin paper. Right. So that question is not going to get asked to anybody who doesn't do a magazine. But this is this is kind of what you want to get at, right? Not everything can do that if you're doing content strategy or if you're dealing with content people. These are also good starting points, right?
You're kind of tracking where content, how it's created and where it goes and who uses it, who consumes it, who produces it.
How does that flow work? What are their priorities? What are their concerns? And for each of them along that path, along that workflow, what is success mean to the. What do they think the benefits are? What what concerns do they have this is not about you selling your product to all these other groups or selling what you want to do to all those other groups. It's finding out what's in it for them and who they are and what their motivations are and how you can help them.
Right, so this is just giving you things for you to go back, ask a bunch of questions, then you go back and you think about how how can you answer those questions for them when you go back and say, hey, how about this? Go to lunch, take them for coffee, go for a walk, whatever it is that you have to do to bribe them to get questions answered. This is the way it's investigation gate strategy, really my other favorite strategy.
Is this one, if you really want to do if you're really believe a pilot is the answer, you want to get your hands on it, you're not really designing an experiment to test whether this is the right product for you. But if you want to just get your hands on it and get a feel for it and see it, take a training class from the vendor.
Right, even the cost of travel and hotel and a two day or three day class is far less than than a pilot implementation and you get the benefit of a product of seeing the product fully implemented completely. All of all the features there. Right.
Even the ones that you're thinking about are not necessarily important to you or you don't think are really on you. But and it's developed and implemented by the team that built it. Right. So you're sort of minimizing the amount of risk and the number of factors that can make something not work well.
You go over there and try it out and play with you got a classroom full of customers to talk to, right?
And you've got you can ask the trainers questions because trainers assume you were already a purchased customer, right. So you're not Galardi.
And I could tell you things you can't do. And I actually this is how I found out one of the products wayas many years ago, that what they told us it could do was not what it could do. The traders that did it. No, no, no. It doesn't do that. It does this this is what that feature does. Right. So I'm going to take a training class very, very effective. So I know you don't want to do requirements analysis and I know you don't want to have to dig into and you feel like I should just be able to ask people what the best one is, but it's never going to work.
You'll have same mess, different tools do the work. It's worth it.
So I'll give you a chance to type in some questions, and before we go, I'm going to talk about the mastermind session. This has been really fun. I was having sequential conversations with a bunch of customers to the point where I figured, hey, we ought to actually all be in the same room because as you're developing what your expertise and you're working on your own projects, you're tackling things in the order that they're important for you and somebody else is tackling them in a different order and you can all learn from each other.
So this is a virtual telephone call support group, however you want to think about it.
And mastermind's have been very been in the news recently through Forbes and on Facebook in the tech on women's group, actually has had a big discussion about this.
And if you're by yourself, sometimes you just need somebody else to talk to.
Really, you just want to bounce your ideas off of someone and maybe it's your team and maybe it's not. And these are all people who are implementing and doing things together. So they're here for you. It's the same. It's not a random bunch of people. So you could actually grow the same people over to in meeting after meeting, get to know each other and have a confidential group to work with.
All right. And our next dojo, the next two months, we're going to talk about preparing legacy products for products for responsible design. And we've got Neil Perlin, the fabulous Neil Ferland, coming in both November and December. So be sure to sign up for that in order to find out where to go. Just come to the dog and you'll come to this page. And you'll see what's coming up next down here at the bottom, and we always post the video for the last session, so this one will go up tomorrow, the last session.
So you can watch it right on the page. All right, and we're currently figuring out the schedule for January, February, March of next year, if you want to vote on topics or suggest one of their own. Be sure to do that here and we'll go find an expert who wants to teach whatever it is that you want to learn. All right. This is who we are. I'm really glad that you could come we try things, experiment and find all kinds of new stuff to do.
All right. Do we have any questions? How you are quiet. But sometimes I know this can be a lot of information. I ran a little bit long, but it's all really good information. You all were attentive toward the end, so I didn't want to end too early.
Happy to have you. If you have questions. Be sure to send email to me and or join the mastermind group and you get all kinds of goodness with that. If you're an individual has less than 40 bucks a month, which is less than you pay for cable. All right, well, we're going to go and this session will be posted to YouTube shortly. Thanks, everybody.
View the Slides
Prefer to read?
This presentation was the basis for an article that appeared in STC Intercomm in May 2016. Read the rehosted version.
- STC Summit 2015
- CM Strategies 2014
- Lavacon 2014
- STC Sacramento 2014
- STC Summit 2016
You might also be interested in...
best practices, content management, make your business case, techcomm tools
CIDM, Lavacon, Presentations, STC, TC Dojo, Webinars
About the TC Dojo
At the TC Dojo, you pick the topics and we find the experts. Join our mailing list so you can attend the next one live. After all, you can't ask questions of a video.