This is an edited and abridged transcript from our ‘In the Ring’ podcast series about discovery. 

For the next six weeks, we’ll be sitting down and talking with Melissa Curra, SUMO Heavy’s Director of Strategy to break down the entire process. 

You can also listen and subscribe to the podcast on Spotify, or wherever you get your podcasts.

https://open.spotify.com/episode/7yJ3hYkOXAKpX63ZFjxZa0?si=146W5VrsQfyK77XGNdECCQ

John Suder: Can you give us an overview of what the knowledge and tech review is and how it fits into the discovery process?

Melissa Curra: Generally, clients have an already stated understanding of what they're looking for, for their site for their project, and the set of features, they have it at least in a bullet point list perspective. Essentially, the tech review is a really deep dive and breaking down of all those needs and understanding things like the effects they're going to have on your budget, your resources, the people, and things it's going to take to get this project done. And of course, the overall timeline, and roadmap that all of this stuff is going to live upon. It gives you really realistic insights into the level of effort and how long your grand project will ultimately take.

John: What is the value of the knowledge and tech review section of discovery?

Melissa: I think the value of the technical, deep dive, and that step of discovery is that generally when you enter a project, you’ll know the broad strokes of what you need. However, all of those decisions and all of those pieces are sitting upon technological solutions, and all of that documentation that you're going to gather over the course of the technical review, and all the resources that you'll have access to really get those solutions down on paper and visualize them in a way that lets everyone on your team be on the same page, everyone understands what is happening, what might be a roadblock down the road. 

Once you have that universal understanding of the decisions that are made, it's easier to change to scale to grow over time, it's easier to understand how much you're really going to spend on this project this product in the long term, or perhaps resources you don't have now that you're definitely going to need. And then ultimately, I think the most valuable part of it is oftentimes, teams will pick a piece of technology, it could be an app, a platform, anything. They pick it because they suppose it's the right solution. They've done a bit of research, they've definitely heard from word of mouth, that it's a good product and a good solution. And it worked for someone. 

However, that doesn't necessarily mean that you have a team with the skill set to handle that piece of technology to handle that platform to handle those decisions long term. And so I think the most valuable part is that understanding and bringing that back to your team and to your decision-makers so that you guys can make solid and holistic decisions together because then that echoes through the rest of this product and this site and these features life cycles. It's just critical thinking, a really nice precedent. And I think that's the most valuable part.

John: Have you ever had a client who was so dug in on a decision of a platform? How do you talk them down, or talk them out of that? In other words, as you had mentioned, they heard something word of mouth, or this other site uses the same platform. How do you have that discussion, if they're a bit stubborn about that?

Melissa: It depends on how stubborn they are about it. Some people have contractual obligations and, and they have to fulfill that obligation. And that's the piece of technology that they're using. And even though it might not be the best scalable fit, we'll work with a plan that they might have, if it's really something that we think it is. So, the opposite of what the team needs. And we understand that the team's not going to be able to scale or build this. We here at SUMO will make honest, and transparent suggestions and recommendations. We might go in the direction of suggesting you work with another, another agency that is just better suited to implement something with adverse reactions for us. 

John:  If I'm not a developer, but maybe I'm a PM, or someone involved in the process and my expertise may not be tech, what is my role during this step of the process? 

Melissa: My role is not a technology role at SUMO, and I'm involved in the Technology Review. I think for non-technical resources with companies that are entering discovery with an agency, the best thing you can do is to join those calls, learn about the technology. I understand better than anyone that you might not understand what they're talking about, and the solutions they're talking about. But it's just valuable to be there. It's a different perspective. Engineers and developers and technical resources are some of the smartest people I've come into contact with. They're so insightful and intelligent, however, their intelligence has its limits. And you as this project manager, a designer, and account manager, whoever you may be, you have your value as well. And your value is providing a perspective of the project's scope, deadline, audience, and user. Sometimes engineers are so smart, they get a bit ahead of themselves, or they build something that's bigger than perhaps what you need it and you're there to keep everyone in check. 

In the other podcast episodes, we talked about process and documentation and decision making and what those things mean, those things don't just go away, because now you've entered a technical phase or a technical conversation. You're there to keep people committed to this workflow, and so that everyone understands the decisions that are getting made. And it's going to be helpful to you, the project Product Manager, to have this map. It's just going to add to your knowledge of the roadmap you're making, why would you go on this long, arduous journey into an unknown region without a map? It'll be good for you, too. So my advice is to join as many of those calls as you can read the notes that are taken Google some of the terms they're using, and it'll make you a more informed, well-rounded project manager or Product Manager.

John: From the design side, I will 100% endorse and agree with this answer. I've been on the other side of those calls for years. And while I cannot consider myself a tech person, at least I can come to play in the sandbox and know what you're talking about. There's definitely a value to that. 

How do other teams prepare for the step? And what should the client be aware of?

Melissa: I think different teams have different methods of preparation for something like a discovery. Again, your Technology Review and deep dives into technological solutions should be happening like throughout your discovery, again, we call it a Weigh-In. It'll be always happening throughout the course of it because you're planning this idea out and all of these separate entities out, and they all live upon solutions. Some people are really equipped with teams. They've had people working there for years, it's a really solid product and site that's perhaps been around, it's just going through this refresh, and they have this documentation. They've been through perhaps processes like this, and they know how to make really solid cohesive decisions. They've been documenting them all along. So they come to the forefront with a ton of stuff for us to work through, and the discovery process becomes more sorting through that documentation, organizing it, and reforming it in a way that looks like solutions to this RFP, this problem is MVP. 

Some other teams don't have those resources, it might be a fresh idea, perhaps recently was a turnover. Or they're just going through this huge transformation. No one has been through anything like this before. So the best thing you could do to prepare is to just think about your product. And as simply as you can start to visualize and document the things you want, the things you have, and the roadblocks you're working with that you would love to just get over. Because the more you could put down on paper, the more diagrams you could make, the better, the better suited you're going to be for finding answers to these problems. I think people get very overwhelmed with how they're meant to visualize what a spec doc specifically looks like, what a diagram for certain user flows might look like. And there is no right or wrong way to document these things. It's very subjective, and as long as you're doing your part, to get information out there, before the discovery starts, you're going to be lightyears ahead of most people who just enter with this, like bullet point list, this RFP, and are totally blown away by the amount of subsequent documentation that's going to come from that list.

John: There's no such thing as under preparing everything has value, the more the better.

Melissa: Yes, well, keeping that every person does have their limits. You do what you can.

John: Do what you can, and start documenting now, even if you're thinking about this in a month, or three months or six months, start that practice now. It's very important to get these things down because people have short memories. And you could be a year from now correcting a problem and not knowing what the origin of it was.