Speakers:

Sean Campbell – CEO of Cascade Insights

Zach Simmons – CEO of Discuss.IO

[Modified Transcript]

[Sean]:

This podcast is brought to you by Cascade Insights. Cascade Insights specializes in market research services for B2B technology companies. Our specialization helps us to deliver detailed insights that generalist firms simply can’t match. To learn more about us, visit our company profile. Also, be sure to check out our free market research resources and don’t forget to sign up for our newsletter.

With us today is Zach Simmons, the founder and CEO of Discuss.IO. Discuss.IO is a very interesting company, not only because of what they do, but also how they do it.

Zach, why don’t I give you just a minute here to explain your role in the company and what you guys offer.

[Zach]:

Certainly, and thanks for that. Discuss.IO is really laser-focused on making the synchronous interview process more efficient and more simple. What we specialize in is having a single online platform where individuals can recruit, host, and execute interview sessions — and then analyze those results. We put it all in a nice DIY package that’s backed by our support team. This allows us to provide researchers and branding teams with a platform that provides Agile market research.

[Sean]:

Excellent. I think you might know where I’m going to go with my first question because of how we originally bumped in to each other, and that question centers on the importance of Agile.

I think a certain percentage of our listener base is saying to themselves right now, “I know what Agile is.” These are probably people that come more from a technological background, maybe even originally from a product development background. Then there is probably another section or our audience base that says, “well, you just mean how you can be more fluid, and be more dynamic when conducting research efforts.”

But Agile is a much bigger and broader subject than that. Given that, would you unpack the importance of Agile: what it is, and how it contrasts with Waterfall, etc.?

[Zach]:

Sure. That’s a very broad question, but at its core Agile is a new product development methodology. Agile differs from traditional Waterfall, like you mentioned, in that your process and turn around time — the horizon I should say – is significantly shorter when you are dealing with an Agile product development effort.

This process really impacts the downstream individuals that participate in concept testing and product testing, and matching that cadence is quite important at a business-unit level.

At a very high level, what we’re looking at is a fundamental difference in how products are brought to market. This approach started in tech but it’s continuing to migrate throughout the entire business landscape. It was pushed, in part, by books like Eric Ries’ The Lean Startup, which has helped popularize Agile-based methods in non-tech based sectors.

[Sean]:

Where you stopped there is a really key point. I think one of the things I’ve noticed, and I know you’ve noticed, is that the Agile mindset is impacting product development in a big way. Perhaps most in technology and software companies, but it’s broader than that, as Agile is now extending its reach into other business processes.

These processes are being asked to move forward using this very iterative and Agile heartbeat as well. I think that lines up with pretty well with what you guys do, in the sense you’ve obviously noticed something similar even in the world of market research.

Given that, please share your thoughts on how Agile is extending its reach into other types of business processes and how Agile is not just a software industry or product development thing anymore?

[Zach]:

Exactly. Market research and the marketing function as a whole really have to march in step with what the product development life cycle looks like.

Market research and the marketing function as a whole really have to march in step with what the product development life cycle looks like.

We have to start with that context as researchers, or as any support function. We have to recognize that if our end clients are ultimately changing how they are developing their products then we have to, as support functions of that life cycle, go and match the same cadence as they have.

Those kinds of impacts are where we see market research being shaken up because traditional agencies, by and large, have not really adjusted their processes around how they bring results to their clients. We’re still very much in the world where most agencies are not Agile-ready, and they are still taking months to go through, set up, and execute a project.

Ultimately, that turn-around time is the key difference that we see from agencies that are focused on Agile: they understand how it works versus those that still are working within a Waterfall methodology of 20 years ago.

[Sean]:

Exactly. Generally speaking, as competitive intelligence professionals, I think that’s one of the things that’s a little bit different between CI and B2B market research vs. traditional B2C focused market research, let’s say. We’ve always been a little more investigative, and more “agile,” simply because the samples we target are harder to reach, hence the approach has always been a little more iterative.

Obviously everyone hasn’t quite taken it to the degree we’re talking about, where you are working in two-week sprints and structuring research so it can done in chunks, thereby matching the stories, timelines, etc.

Let me switch this to what I think is a really important part of Agile projects, which is the relationship with whom Agile folks would call the “product owner,” whereas a market research team would call it the “key stakeholder,” and same with the CI team. So how do you produce Agile insights and then deal with the consumption of those same insights in an Agile way? Because one of the challenges with Agile, of course, is you have to have an involved product owner. Otherwise, you basically just ship a bad product in smaller chunks.

I find organizations like the idea of Agile, but they have a harder time actually doing their part when it comes to Agile.

So, what’s the best way to deal with the consumption of those insights? Because, I find organizations like the idea of Agile, but they have a harder time actually doing their part when it comes to Agile.

[Zach]:

That’s a very good point. Let’s take a step back and first talk about the concept of the product owner.

The product owner is the keeper of the product vision. They are the individuals that are driving, walking, and tackling the development of the roadmap and those kinds of things. Basically, the product owner is not just a stakeholder, but also the one with the most questions. When you are supporting that product owner they should be able to identify what the critical questions are for the next two- to eight-week time frame.

Normally, they’re answering individual questions and are not looking for exhaustive conclusions. Rather, they are focused on developing a continuous strings of insights, and obviously the questions will change as they’re navigating their own roadmap.

[Sean]:

What’s a good set of best practices when it comes to coaching the stakeholders and product owners on what they are about to receive?

Those are all really good points. Let me ask you a follow-up question: What’s a good set of best practices when it comes to coaching the stakeholders and product owners on what they are about to receive?

I imagine, like most things that are different when it comes to business processes, that people carry their preconceptions with them a little bit. I imagine there might be a little bit of, “Well that’s great! You’ll give me more stuff more quickly, faster, I’ll see it more often, and I’ll have as much time to decide as I used to.” And they think they have all the time in the world to give you feedback.

How do you guys go about essentially educating? Obviously you’re working with the agencies in this regard, but I imagine there’s a lot of discussion about how those agencies educate their end stakeholders.

Zach:

Exactly right. It’s very much a training and “feeling each other out” scenario, and we learn as we go with our clients.

One of the key characteristics is the concept of ongoing deliverables. Small pre-selected kinds of things that you build a set of studies or deliverables in your mind; having that steady stream of deliverables so you are always actively engaged as more than just the market researcher, but you are the information partner that is delivering insights throughout that process.

Your deliverables may not even be clear to you as you enter into an engagement for something that’s three months down the road. Rather you have committed to, under some kind of retainer model or such, creating that type of recurring insight — and you’re again a partner at the table when people are doing what they call the “sprint planning cycle.” Being involved and knowing what those critical questions are that the product team need answers to as they’re starting to form is really the best way to insert yourself as, again, a key partner in the process.

Being involved and knowing what those critical questions are that the product team need answers to as they’re starting to form is really the best way to insert yourself as, again, a key partner in the process.

[Sean]:

True, but one of the things I’m sure listeners are thinking about is this: What happens when my stakeholders, in singular or plural, have left the building? Perhaps for no fault of their own; they’re just completely unable to interact with me, perhaps for weeks at a time. Is your recommendation that the project, by necessity, must pause if there’s no meaningful backlog to work through, or if there’s a real chance that the story prioritization has to really change and you have to wait to get said feedback?

Because I think one of the “benefits” of the larger scale projects, if I might put it that way, is that some people think the vendor will continue to work without my interaction to some degree. Agile presupposes that the stakeholder / product owner is fairly well engaged, and that you and the research vendor have an ongoing seat at the table.

But we both know that in the real world, sometimes the stakeholders check out and it’s not so much their fault as they’ve just moved to other things for a period of time. So if they don’t have the ability to pay attention to the project, or to tell whom they report to, I imagine that can create some real challenges in terms of project flow.

[Zach]:

Yeah, this is a very good point that listeners should pay attention to. It’s very important you develop a relationship with your product owner and your stakeholders that recurring and ongoing research is something that happens whether or not they are involved directly.

Having some kind of database of questions, we will say for simplicity sake, is vital because the moment that a week goes by without any contact or deliverable – and if the bus just stops – then you’re dead. The whole project no longer is a continuous stream of deliverables.

You have to make sure that you, as an insight professional, have accumulated your own backlog, so to speak, of deliverables — and therefore you have a relationship in play such that the product owner knows that every other Friday there will be some kind of deliverable on their desk. If they’re really engaged it will be the exact deliverable that they wanted, if they were less engaged it might not be. They have the expectation that it is on them to help nurture and support you as a partner searching for the same insights that are keeping them up as a product owner at night.

[Sean]:

One of the really big benefits that I want to make sure we don’t forget to mention is that Agile avoids surprise endings — unlike a Waterfall-oriented market research or competitive intelligence study.

Yeah, excellent point and good coaching, too. One of the really big benefits that I want to make sure we don’t forget to mention is that Agile avoids surprise endings — unlike a Waterfall-oriented market research or competitive intelligence study. When the vendor goes off for x number of weeks or months and comes back and presents to the room full of executives, there can be a lot surprises at that point, and sometimes not always pleasant. What you are sharing may be accurate data and insights but it can still create surprise.

Hence I think one of the benefits of Agile is that you have the ability to socialize and essentially avoid surprise while still getting insight. I think that’s a really powerful coupling, especially when you are talking about research and large companies as your client.

[Zach]:

This is actually the original reason why Agile was created over a decade ago. Software developers were running into the exact same thing. They’d run off… take in requirements, talk with some users, spend nine months building something, and then there was a giant reveal.

They kept missing the mark. Projects would go over, they would be expensive. This is exactly what Agile is there to solve, and market research has paralleled to that same place. So today, you need to create an ongoing relationship and ongoing deliverables that engage the stakeholder. That engagement helps socialize the information, which makes sure that there are no surprises, and that helps to create buy-in. It’s a much more collaborative process and relationship with your ultimate consumer of those insights, and ultimately more productive as a result of that engagement.

Sean:

I agree, and I think that’s a good place to end it. With that, thanks for joining the podcast and thanks to our listeners for being along with us — hope to have you along on the next episode.