The Benefits of the Product Process
Octavia Threlfall, a senior associate in BRG’s London office, walks through the newly established product process of BRG DRIVE, the firm's analytics platform, and the benefits it can bring to users.
TRANSCRIPT
MJ Hi, everyone. This is Michael Jelen, and welcome to the BRG Global Applied Technology podcast. The GAT team, as we call ourselves, is a globally distributed team of software engineers, data scientists, graphic designers, and industry experts who serve clients through our BRG DRIVE(TM) analytics platform. We're helping some of the world's largest and most innovative companies and governments transform data into actionable insights.
Today I’ll be speaking with Octavia Threlfall, Tavie, from our BRG GAT team. Tavie is a senior associate with over five years of project and team management experience. If you’re familiar with our team, you’ll know that we leverage the BRG DRIVE software platform to provide solutions to our clients. What you might not know is that every solution or product that we build follows a rigorous product development process. In this conversation, Tavie introduces this process and speaks about how important it is to ensure that our software products are viable, a good market fit, and competitive.
As always, if you have any questions, please email us at gat@thinkbrg.com. And with that, let’s jump into this conversation with Tavie. Hi, Tavie.
TT Hi, Michael.
MJ Good afternoon. It's a pleasure to be talking to you today a little bit about our product process. Could you tell everybody a little bit about who you are and how you came to work in this team?
TT Absolutely. It's a pleasure to be talking to you too. So my name is Tavie. I've been with the GAT team for about three-and-a-half years now. I actually started as an executive assistant for the team, but as I took on more responsibility and project work, I progressed into an associate role. I'm from London. I studied marketing at university in Manchester. And I've been really lucky to be involved with the GAT team. So many different people to learn from.
So I know you spoke to Julie [Coope], who's from a nursing background. Kevin [Hamilton is] an engineer. And then you've got Matt [Felici], who's a designer. And different products as well. I've been working on government projects, healthcare projects, and also internal projects. So our sales pipeline and our product process, which is what we're going to talk about today.
MJ Exactly. And it's been great spending time with you in the Middle East working on some of those projects. You've really seen the team grow and change from the beginning point, where we were really just developing a platform that tried to be everything to everyone, and you were really the spearhead in leading us towards moving into this product-focus type of an area.
So do you want to talk a little bit about, at a high level, what is the product process, and why have we switched over to start working with products, rather than just a more broad software platform that has a lot of different services and utilities?
TT Sure. The product process is very new to this team, and we've made the switch rather than having one product, because DRIVE is kind of one big solution for everything, and it's difficult for clients to see how it could specifically help their needs. So we've chosen to split it out into specific products so we can have different use cases, different demos—so it can be a bit manageable for clients.
MJ I think that that's absolutely right. I mean, there are some clients we have in financial services who are using this certain configuration of forms and workflow and analytics in a completely different way than our clients in healthcare are using that same kind of set of tools. So if you were to do a demonstration for a client in the healthcare industry using financial services data, it really doesn't make a whole lot of sense. They want to see something that is very relevant to their data, specifically. And so while you've been developing this product process, where do you start, or how do you start to put something together, so that we have stages and we can make sure that these different areas are focused and meeting a very specific client need?
TT Firstly, you need to ensure that the products are created to fit an actual customer want and need. And then you need to make sure that the product feature is always focusing on that need. So you want to prevent scope creep. You want to ensure that your resources aren't wasted on different research. And so ultimately, you're making sure that you're not building a product that ends up no one wants it. No one needs it. You're building something that people actually will find useful and that will sell in the current market.
MJ I think that's very important, and that's a lesson we learned the hard way. I think being out in the marketplace and working with clients, when you hear that they have a certain need, we want to just jump in and try to meet that need and build that service or tool or product for them, specifically. But usually, we lose sight of the rest of the marketplace, or being able to generalize that, take a step back, and see if it's something that is a problem that lots and lots of other clients have been experiencing as well. So where do we get started in this process, or what's the beginning of it?
TT We have eight stages in our product process. So the first three stages act as market checkpoints, and that's discover, define, and design phases. And they're basically there to make sure that we are meeting a need and that there's a market for the product and that the product features align to that need.
The next four stages are the product life cycle. So that's develop, deliver, drive, and decommission stages. That's where we'll do the making, the marketing, and the upgrading. And finally, the sunset of the product, if necessary.
The eighth stage, at this point it's not applicable to all products, but it's equally very important. So if a product does not meet the specifics of the first three stages, it should go into desist, which is when you stop making the product because it's not viable. You have to be kind of brutal, sometimes, when dealing with your ideas, because you can get excited about ideas. But if it doesn't meet the market needs, if it doesn't solve a problem, then there's no point in building it as a product.
MJ What are the kind of questions that we would be asking clients, or how do we try to understand their need? Because in some situations I think we've worked in an industry for a long time. We're talking to other experts at BRG who have experience in that area. But what are the real ways that we get underneath the surface to understand what the real problem is that they're trying to solve? I know there's that famous quote that Henry Ford always says that if I gave people what they wanted, I would have given them a faster horse, something like that, rather than building a car. What are the ways that we understand from a client what it is that they really are trying to solve?
TT So the first phase is the discover stage. At this point, the product really is just an idea. So at this point, we need to determine three things: the problem being solved and who it's being solved for, the scale of the competition, and how the problem is being solved at the moment, and the total addressable market.
MJ Okay. Well, let's drill into each of those. So first, I guess, how do we figure out what the problem is? Do we talk to just one customer or a couple of different customers, or how do we start that process?
TT Client can come to you and say, "Hey, we have this problem. We need help solving it." Which is great. Obviously, you're going to help them. But it's also important—and this mistake’s been made in the past—to see if this product is viable for sale in the actual market as well.
MJ During that process, we're also doing, I guess, a little bit of market research. You mentioned the total addressable market. Can you talk about how we'd come up with that, or how we calculate that, and why that's important?
TT Sure. So the total addressable market or the TAM should answer specific questions. So how big is the market? Is it growing? What are the risks and the entry barriers? And how can a product remain relevant? So the total addressable market, it looks at the competition as well. So how things are being done at the moment, how you can do those better, and ultimately save a client time and money. At the moment, we have in the discover phase a tool that could possibly be used for managing supply chain data to ensure that process is being followed. TAM will be taking place, and then once those have been assessed, they'll be documented in an innovation canvas. And at the end of this stage, the product owner will need to get approval to fund a business plan, and at that point, will go into the defined stage.
MJ All right. So in the discover phase, we're really trying to assess, is there a problem, can we meet this need, is there someone else meeting this need in the market, and how big is that market? So it's really trying to understand, is there a business viability for us to move forward and evaluate whether it's worth to build something or not? Is that right? And then after that—
TT Absolutely.
MJ —we start to get into defining what that is, right?
TT So, yeah, you're right. It kind of just makes a start on: is this actually possible? And then we go into define. So that's when you'll do detail competitive analysis, create potential user personas, and define the features and functions of the product.
MJ Okay. And how do we go about doing that?
TT You'll put yourself in the mindset of a typical expected user of a product. So, for example, you'd imagine you're a clinician for a healthcare performance improvement tool. So you'll include details of the user's behavior patterns, challenges they face day to day, their attitudes—so for example, towards technology or adopting new things; their working environment; and their skills and their goals. And you'll kind of imagine yourself in this person doing their day-to-day role, what questions are they going to be asking, and how they can answer them.
So, for example, a clinician for a healthcare performance improvement tool, you may think, "When I'm asked about my ward's performance, I want to be able to see an analysis of that performance against my peer hospitals, so I can see where the opportunities lie for improvement." So it's a “when I want to, so I can.” And these really can develop your features and functions and just to make sure that they are current to the needs of the customer.
MJ Got it. That makes total sense. So in the first phase, we're saying, "Is there a problem? Is there a business viability for us to move into it?" In the second, we're putting ourselves in the shoes of the customer to say, "Now that I am experiencing this problem, what would be the best way for me to solve it?" Or we go through these customer interviews where we're probing into the day-to-day life of these individuals and trying to figure out how we can make their life a little bit easier?
TT Absolutely. Yeah. And this is really important this stage, because if you're—also, user interviews can take place at this stage, which is really important. Because if you're not interviewing potential users, you won't have an idea of what they want or need. So this has happened in the past. You kind of build a product without research or validation and you end up with a product that, kind of, people don't really—they don't need, which is a waste of everyone's time. So that's what we're trying to avoid. [laughter]
MJ That makes total sense. So when we're doing these customer interviews, what are some of the specific items that we want to include in the business case? So I guess we're going to do a number of different customer interviews. We're going to try to aggregate that information. Then, we're going to build it into what we want to move forward. What are some things that we should make sure we include in there?
TT We do want to then document this in the business case, and that will include things like the market problem, so what we're trying to solve; the market conditions, so what's happening in the market and why it suits our solution. You'll want a description of the product and the solution in there. You'll also want to have our credibility in the market. So, are we known in the region? What are we known for? Because, as you know, we're a global team. We work globally. Does the product fit our strategic goals as an organization? What are the risks and assumptions? And finally, you'll want some financial information in there. And that will include the development of the product, the ongoing maintenance cost, your return on investment, and the suggested price.
MJ Okay. And so at this point, once we gather all that information from customers, we're asking them how much they'd be willing to pay for it, that sort of stuff—we bring that into a business plan and there's kind of a go/no-go decision that happens at this point, whether we want to invest more time into this path, is that right?
TT Yeah. Exactly. So there’s a kind of a decision after each stage. But you’re right, these three first stages are very important in that process. Which brings us to the design stage, which is the final stage in this market checkpoint. So you’ve done your customer research. You can imagine the product. You can imagine the solution—what it’s going to do. So this is where you really want to see it come alive. So you’ll go through designing of the features and functions. You'll develop use cases. Matt, who you already spoke to, will develop a wireframe. So you can really see the product.
MJ Yeah. And I think this is a very important phase for clients, because I think at this point, we would start to work together with a couple of them in a small focus group to understand what the ideal way of using this, what the user experience would be. And I do know from speaking to Matt that … it's very challenging moment for him. And he really tries to take a big, wide perspective on what the best possible use case could be or the best way to work through solving this from a technology standpoint is. And then sometimes we present this to clients, and you get mixed reviews on that. So I think there's a level of refining that goes into the wireframe as well.
TT Absolutely. And that's where you can really develop your USP. Because once your clients are seeing what you've got, and they're asking questions, they're seeing how this is better, how it's different. And also, on the other side, you're right. They're saying, "Actually, no, we don't need this. We need this instead." So, yeah, I'm imagining it's very tough for Matt, but he's great at what he does.
MJ Cool. And so during this phase, as we're going through and designing, I guess we're keeping in mind the idea of putting ourselves in the shoes of the customer and trying to think about this from their perspective. Is there any sort of official documentation that goes along with that, or is there any way that we try to ensure that this wireframe is meeting the needs of the client?
TT Yeah. So we have a value proposition, which is a document that needs to be completed. And that kind of determines who the target users are, what their needs are, how it's different from the competition, the USP, what our clients think of the product. And all that information will come together. And this is the final market checkpoint. This is where approval is granted or when the decision is made to, should we proceed this product into development, or should we go to the desist stage?
MJ Okay. And so it seems like, yeah, we've already invested a ton of time in customer interviews, trying to scope the market, understanding what the competitive analysis is out there. So all of that goes into this before we even give this product any sort of wings to go into the development cycle, is that right?
TT Absolutely. It's a rigorous process, but it is useful and important. It's interesting, because we're going through user interviews with one of our products at the moment, in retrospect. It's already been developed and delivered, and just documenting it in the product process. And it's actually very interesting, because some of the assumptions we made were not the overall outlook of the client. So, yeah, we just want to avoid that kind of thing in the future.
MJ Yeah. It is a challenge. I know that we've adopted this product process after already having some things out in the marketplace and after having already sold a few things. So we are trying our best to align all of our existing products to that. And in some cases, the assumptions that we made at the beginning might not hold true when we start doing real customer interviews and following a rigorous process.
TT Absolutely. And that's definitely what we're trying to get into motion at the moment.
MJ Yeah. So now that we've wrapped up those first three phases, which really are focused on validating whether or not this is something we want to invest more time in, it seems like there's a fundamental shift as we move into the development cycle, where now a different set of team members are involved. Probably the way we have to manage the development is going to be very different.
TT Yeah. Absolutely. Now we have made a decision: we are going to proceed with building this product. So this is the developed stage. So this is where detailed design plans will be made, the features will be confirmed, and basically, the user interface will be built. All the while ensuring that the original needs of the product and problem to be solved is still being met.
So I actually did a project management course last year, which I know is project, but it kind of links to this. So it was Agile, and we learnt about MoSCoW prioritization. So that's your must-haves, which is a non-negotiable product need. Your should-haves is what you should have, but it's not vital. Could-have is, well, it speaks for itself, really. You could have them, but it would be little impact if it's left out. And will-not-have. So this is kind of the same as nice to—well, sorry. Could-have is the same as would-be-nice-to-have. And then will-not-have is something that's not a priority for this time frame, but you can have it in future developments.
MJ That does make sense. It's super relevant because we're now moving into the phase where it is a project now. It's going to be something we actually work on and build. Whereas the first three phases seem like they're more at a business level. We're assessing whether or not we want to move into it. But now that we're in phase four and we're starting to develop a piece of software, we definitely need to manage that in a certain way. And so Agile and all of the things you've mentioned are perfect for that situation.
TT Absolutely. It is a very Agile approach, because you need to decide which features are important for the launch. And that brings me to the next part of the process, go-to-market launch. So the go-to-market launch is what you'll need to go into the next phase. So this is basically a list of questions. And if any of the responses are no, you seriously need to think about whether it's ready to go into the deliver stage.
So for example, the questions can be, have the legal team reviewed the product language? Do your client-facing teams understand the customer journey?
MJ So now that we've developed a product, we have something that functions, and we're able to go out to the market with. Before we do that, I guess it's important to go through this questionnaire of things to ensure. One, is it legally allowed out in the marketplace? Has legal reviewed it? Probably a couple other things to just cross the ts and dot the is and make sure that everything is sound and professional enough to go out to the marketplace, is that right?
TT Yeah. Absolutely.
MJ Okay. Cool. So then once we've got that product and it's been developed, we move into—would this be the fifth phase?
TT Yeah. The fifth phase, which is deliver. So this is where the launch of the product will happen. So the marketing campaigns will take place, and you'll establish a client base. And this is where you can really see different customers in respect of the product adoption. So the key is to engage the early adopters first, which is going to encourage the early or late majority, those suspicious of new ideas or products. So, for example, at the moment, we're going through this stage with one of our products, and we're using Google AdWords to kind of assess what people are searching for, assess the current appetite, get the keywords out there, and see what sticks, basically, which is really interesting.
MJ Absolutely. So … if we've got a marketing campaign set up, that would be also measured, and we'd have analytics on top of that to ensure that we are constantly moving through this process with a data-driven environment, I would think, to ensure that we're backing up any of our assumptions or any of our thoughts or hypotheses with information from the marketplace?
TT That's right. And that takes us to the drive phase. So once the product is successfully out in the market, the drive phase will start. So that's when you'll have client-centric research and feedback. So you'll go to your client, and you'll say, "How is this working? How is it not working?" And that's really useful, because you can then start to develop new features, new functions. You can have a look at the competition again, see what they're doing.
It's a really important stage to stay current and competitive in the market. A product can go through these three stages, can iterate through these three stages, for quite a long time. So kind of developing and delivering new features and driving these in various markets. So you could try a different market somewhere else in another country or another industry. So at the moment, we have one product, but we're targeting nonprofits, and we're also targeting higher education. So that will kind of keep going through the product life cycle when you have new features and functions.
MJ And so this is the place where products stay for the longest. As long as there's a market need and things are evolving and changing in the marketplace. We're constantly monitoring what's going on, talking to our customers, understanding if their needs are changing or what new features they want; and then going back to the developers, incorporating those in as new features, delivering them, testing them, that sort of thing, right? So most of our products are going to stay in this four, five, six, develop, deliver, drive cycle for most of their life cycle?
TT Yeah. And that's why it's so important to kind of not just forget about a product once it's launched into the market. You do need to kind of stay focused. Stay in contact with your client. Keep an eye on the market and the competition just to make sure that you are progressing through these stages. So, yeah, you're right. Most products will stay at this stage for a long time.
However, eventually, they're going to reach a stage where they can't compete in the market, or they need to be decommissioned or replaced. This is a decommission stage. So you'll monitor the market, and once people have kind of stopped using the product or once you've launched a replacement, you'll launch a sunset plan. And that's going to close out the product and take it off the market.
MJ And I know our development team really does enjoy this sort of thing, because for us to take products off the market, it means there's less maintenance for them, less code base that they have to make sure that they're staying on top of. And so, yeah, it allows us to kind of focus ourselves on the bets that are really paying off.
TT Yeah. That's true.
MJ Perfect. And I know we use a set of different tools in our team individually to manage the different areas. So if we were to cut up these seven different pieces or seven different phases of what's going on into the first three, which are really the high-level business objectives, to understand if there's a market need and a fit; and then the final onward—develop, deliver, drive—that that mostly deals with our engineering team and it's about building and getting features in there and that sort of thing. Do we use, or can you talk a little bit about, the different tools that we use inside of our team to manage that process? Because it is two pretty separate audiences who are touching this at different areas of the life cycle.
TT Yeah. Absolutely. So I'd say there's four tools that we use. So we use Trello for a high-level overview of where all the products are at one time in the process. We use Productboard to kind of prioritize new features, rate them. And then we use JIRA for the development guys to actually develop them. And then we use Salesforce to drive the products.
MJ Yeah. Salesforce is also where you do any of your marketing campaigns, is that right?
TT Yeah. So we keep all our marketing campaigns in there. We keep our contacts, all our opportunities. So it's easy to organize. You can see where you are, you can see where your bottlenecks are, and you can see who you want to target next as well. So, to summarize, communicating with your clients or completing market research is key when developing a new product. Otherwise, you risk developing something that no one wants or needs. Using a range of platforms ensures organization of not only the products at a high level or at a feature level but also marketing campaigns and keeping track of opportunities in the deliver phase.
MJ Thank you so much for taking the time to do this.
TT No, thank you.
MJ Awesome. Well, I will talk to you in two minutes. Thank you. I really appreciate it, Tavie. Have a good one.
TT Bye.
MJ Bye. The views and opinions expressed in this podcast are those of the participants and do not necessarily reflect the opinions, position, or policy of Berkeley Research Group or its other employees and affiliates.