Summary

• There is plenty of hype around the term Citizen Development and the role of Citizen Developers. We know that the term might be new but the concept is not.
• Matt Hubbard, Head of Operational Excellence at TrackVia, Inc., shares tips, tricks, and methodologies to sustain your Citizen Development initiatives beyond simple Proof-of-Concept apps.  
• Prior to joining TrackVia, Matt co-founded his own consulting firm specializing in business process management and low-code technology.
• The core of Matt’s mission is his belief that process, technology, and people must be optimized together to achieve a lasting result.
• In this episode:
• • Matt Hubbard’s journey of becoming a Citizen Developer (long before the term existed)
  • Moving beyond simple PoCs to a sustainable CD program
  • Project Management Institute's Citizen Development Framework
  • Advice for companies dipping their toes into the Citizen Development world
  
  

Key Takeaways

Transcript

Guest Introduction

Sharjeel (01:51):

Today I'm talking to Matt about ‘Moving beyond the Hype of Citizen Development’ and how to make it sustainable.

As Benjamin Franklin said, Tell me and I forget, teach me and I remember, involve me and I learn, that's where I like Matt's advice of not overthinking and getting started with the basic course offered by Project Management Institute. It's called Citizen Developer Foundation Course.

And as Matt narrates that once people take the foundation course, they're so excited that instead of taking the next PMI course, they're ready to jump into the tool and build new things for themselves.

And I was impressed by Matt's ability to really glue together three aspects of Citizen Development, the basic definition and concept of Citizen Development, how it typically starts in companies. Thirdly, how to make it sustainable and scalable beyond pilot projects? It's time to listen and learn. It's time to hear some words of wisdom from our today's featured guest.

So, Matt, can you please introduce yourself and what's your role at TrackVia?

Matt (03:09):

Yeah. Hi. Sure, Sharjeel, thank you for having me today. Before I introduce myself, I just want to make a disclaimer for your audience, and that's that I'm not a morning person and this is a morning interview.

So normally, I like to bring some energy to the interview because I'm very excited about Citizen Development, which is what we're going to be talking about today. So hopefully I'll get that energy as we role in here as we progress.

To introduce myself, my name is Matt Hubbard. I'm Head of Operational Excellence at TrackVia. TrackVia is a low code no code platform upon which business applications can be built quickly and effectively. And my role at TrackVia is to help our customers get the most out of their investment in our technology. And I do this in two ways, and I'll describe each in a little, little bit of detail.

Matt (04:03):

The first way I help our customers get the most out of their investment is I help them with process improvement. So I often preach, never automate a crappy process unless it's your goal to produce crap faster.

Now, that's, that's kind of funny, that's kind of tongue in cheek, but the truth is that today's low code, no code technology, it allows us to build automation apps so fast that it can be tempting just to jump straight to the technology without first considering the process.

But if the process and the technology aren't harmonized to support each other, the results can be poor. And I'll give an illustration for this, that some who maybe are a little older, like me, might remember that there was a sitcom years ago back when TV was black and white. It was called “I Love Lucy”.

And there was a famous episode at the Chocolate Factory, and Lucy and her friend were employees at a chocolate factory, and their job was to wrap candy as it was coming down the conveyor belt.

Matt (05:16):

This was their first day and they were trained kind of haphazardly on how to do the job. So, I wouldn't say that their process was strong, but then the company decided to introduce, we'll call it automation, but it was really just speeding up the conveyor belt. So, it's a really hilarious episode.

I encourage you to go watch it on YouTube. But, basically they sped up the conveyor belt. The process did not match this speed of automation. And so Lucy and her friend, they, they were picking up chocolates stuffing them in their shirts, stuffing them in their hats because they were told that they would be fired if they let one piece of candy go by that wasn't wrapped properly. And, this automation, so to speak, stressed them out. It created chaos and really resulted in bad quality.

Matt (06:06):

So, I think that the illustration fits well to say that it's important to think through processes before flipping the automation switch. And that's what I help our customers do.

And the second way that I help our customers get the most out of their investment in our technology is by teaching them about Citizen Development, which is what we're going to talk about mostly today.

Our product TrackVia is a platform for building apps. You can use it to build one app that solves one single problem, or you can use it to build multiple apps that solve an abundance of problems. Using low code, no code at scale can be a competitive advantage, but it must be approached in a wise fashion. And, so it's my role to teach our customers a Citizen Development framework and best practices that will allow them to grow with low code, no code safely and effectively.

Citizen Development in Real Life

Sharjeel (07:05):

Now, that's pretty comprehensive Matt. I guess that's both ends of the education process. Not only do you improve the process but you approach it wisely, and that's great.

So, the term Citizen Development might be new to many folks, Matt. So, what is it and how to do it, and how did you get involved with it.

Matt (07:33):

That's a good question. Yeah, the term Citizen Developer or Citizen Development, I've actually had some people tell me that it sounds like a weird nefarious plan for the government to control their citizens. That's not the case, of course, but I get it.

It is kind of a weird term. So, let me do my best at trying to describe what it is. I'll kind of describe it real high level, but then I think the best way for me to illustrate it is to tell you about my Citizen Development journey and how I got involved in it.

So at a high level, Citizen Development is about safely empowering people who are not formally trained coders to build their own software applications through the drag and drop capabilities of a low code no code platform. The best way I can describe is as follows.

Matt (08:27):

Low Code No code is like a box of Legos. So, instead of having to build something from scratch with all the raw materials, you just grab an existing Lego block and you start piecing it together with other blocks of different sizes and different purposes to create something quite magnificent.

A child can create a house, a car they can create the likenesses of people and characters all with the same box of Legos. And, so that's what a low code no code platform is like for software development.

You as a non-coder do not have to build the app from scratch by coding. You can grab existing widgets and start piecing them together into applications such as workflow approvals, tracking, reporting, all of these different types of applications. But like I said earlier, I think the best way for me to illustrate Citizen Development is to just tell you about my Citizen Development journey.

Matt (09:32):

Why and how did I become a Citizen Developer? I'll tell you this story in three parts because they all build on each other.

First, I'll tell you about my problem solving nature, and then I'll tell you about a failed software project that I was responsible for, and it ended up being the catalyst for me to look into Citizen Development.

And then the last thing I'll tell you about is actually my first experience with low code no code and becoming a Citizen Developer.

Let’s start with my problem solving nature. I want to start there because that's who Citizen Developers are, they are problem solvers. If you are one who is okay with the way things are today, you like coming in, doing your job, check the box and go home, then I would probably say Citizen Development is not for you.

Matt (10:25):

Citizen Developers are inquisitive. They want to look at something that exists and make it better, and they want do so with technology. So, that's kind of who I am by training and at heart. I'm a problem solver. My education is in engineering, and my first job was as a quality engineer.

As a quality engineer, I solved problems reactively and proactively. And, reactive meant fixing the quality issue after it already occurred. While proactive meant preventing the quality issue from occurring in the first place, I much preferred working on proactive prevention and would do so by controlling the processes that would ultimately produce the result.

Now, my favorite tool for controlling the result was something called Poka-yoke; it's a Japanese term that means mistake proofing. For example, you put a physical attribute in an assembly fixture, and it makes it impossible to install a right side part where a left side part belongs.

Matt (11:39):

And, it was satisfying because it was consistent and reliable, and I could count on it to produce the same result every time.

Now, what does that have to do with Citizen Development? I think I'm illustrating this because this level of control that I came to appreciate in manufacturing became the baseline for what I would expect later from my software projects.

And so that brings me to the second part of my Citizen Development journey. And that's my first software project, which frankly was a failed software project. This was the catalyst that pushed me towards Citizen Development.

So, after a few years of being a quality engineer, I was asked to lead a large back office project that would require standardization of 10 business processes and the development of software to control them. And as I said, this was my first software project, and frankly, it didn't go well at all.

Matt (12:42):

The team and we succeeded in improving and standardizing the 10 processes on paper.

But personally, I failed at getting the software developed. I was thorough in documenting the system requirements as I leveraged the same error proofing and process control mentality that I learned as a quality engineer.

But, I was astonished when I got the quote back for what it would take to build this software that I spec’d through my requirements.

The cost was in the millions of dollars. The timeline for developing it was on the order of several years. And then the flexibility was virtually non-existent.

Basically, I had one shot to get it right because the project team and the coders, they will have moved on. They have other projects to focus on, and frankly, this lack of flexibility is just not realistic. How could we possibly get something of this magnitude right the first time?

Matt (13:45):

What about continuous improvement? What about changes to the business?

We will have to continuously update this. So, I need flexibility. So the bottom line on this software project is that I could not justify the software without slashing the requirements to the point that we might as well stick with what we had, which was an old green screen system, spreadsheets, email, and shared drives, which I'm sure many here can relate to.

I failed to deliver on this project. I'm happy that a vision was trapped in my head for a better way to develop software. I thought there had to be something less expensive, faster, and more flexible, but still robust.

And I'll give you a little bit of an analogy here. This is how I thought about it. I thought about it in an analogous way to how Atari brought the home console in cartridges to the video game industry.

Matt (14:52):

So, before Atari did that if you wanted to play a video game, you had to go to a bowling alley and play this one standup machine like Centipede or some of those other ones like Asteroids or Space Invaders.

It played one game. It costs several thousand dollars, and it was not accessible to the masses. And then Atari came out with this home console unit that I think costs like $99. And, then they just had cartridges for each video game, right?

So you could buy a different video game, plug it in and play, and it only costs like, I don't know, I can't remember the prices, let's call it $30 for each cartridge.

And so I thought, why can't we do that with business applications? Why can't we have a platform that already exists, like the home console for Atari?

Matt (15:45):

And then all you're doing is plugging and playing your processes and adding on top of that platform. So, I shared that vision with some of my colleagues. And, actually several years after my failed project, one of my colleagues called me to say that they saw a demo of an app building platform that looked like the vision I described.

And, I checked it out and confirmed that indeed it's what I was looking for. But the irony here is I was leaving for another company in a week after, after I checked it out and figured that would be the last that I'd see of that app development platform.

So, I was extremely disappointed. And this brings me to the, the final, in third phase of my story, my Citizen Development journey story. This is where I switched companies. And when I got there, it turns out that seeing that app development platform was not a disappointment because this new company that I worked at it had similar process and system problems as my prior employer.

Matt (16:52):

So, it turns out that these process problems and system problems are kind of ubiquitous. They kind of exist at every company. And, this app building platform, which would later be categorized as low code, no code was back in play. And to make a long story short, I started learning the platform and building my own apps. I'm not a coder; I'm a process person.

Through low code, no code, I could build some very effective apps and control my processes, like I had envisioned before. And, so a few examples, the very first app I made was just an app to chase down status updates. It took me, let's see, it took me about eight hours to build, but it saved me 200 hours of chasing down status updates a year. So that was a 25 x savings.

Matt (17:46):

The second app I build was for price change approvals. If you wanted to change the price of a part you had to go get approvals, up to 15 approvals depending on the price change percentage. And through this app, we were able to get the number of approvals down to five. And we never lost a piece of paper because it was electronic, where before it was paper-based, people would get to approval number 14 and then lose the paper and have to start all over.

And, the reality is they just they didn't follow the process consistently. This app forced it to be followed the same way every single time. And then the third app that I'll mention real quick is one for procurement requests where buyers would request their purchasing assistance to do some kind of work.

Matt (18:37):

They would do it through email, and everything got lost in email. Not everything, but many things. And so there was chaos. I made an app to control those requests in one place. And we basically created order out of chaos. And so I would describe low code, no code as my superpower.

I enjoyed solving problems with it so much so that others took notice, and they asked me to teach them to build apps on this low code, no code platform to solve their business problems.

And we formed a team of five different people leading and building apps for their area of business. And I was pretty proud of it. But the thing that I'd say I wasn't proud of is that we couldn't scale beyond our immediate circle of influence.

Matt (19:30):

So it was just the people around me who knew me that were willing to take the chance and learn low code, no code, but we, outside of that circle of influence, we did not expand.

I felt like the true value of low code, no code and Citizen Development was not being realized by keeping it to this pocket of five people. Later I started a consulting business. I started a consulting business where I was helping other companies solve their problems through low code, no code and process improvement.

And I tried to teach Citizen Development at scale, but I didn't move beyond these individual projects. I didn't get any sustainable Citizen Development culture to happen. Let me, let me just stop there. Those are my three phases of my Citizen Development journey.

Sharjeel (20:29):

That's awesome. It reminds me, like the particular examples that you have shared, like status update app or price change, approvals, procurement requests, these are all things that IT won't entertain in a typical organization. And the resource would be frustrated that they're not listening, listening to him or her. And I guess the, the route that you took, that's the future, of making your own professional life easier through apps.

Matt Hubbard (21:06):

Yeah, sure Sharjeel, I would agree that it was effective and it is the future. But, I think one of the reasons why it didn't scale for me is because I didn't approach this in partnership with IT and executive leaders. I just kind of did it off in a corner. And so I think that kind of gets to this conundrum of how do we make it scale?

The Culture of Citizen Development

Sharjeel (21:37):

Yeah. This leads me to something that I've been thinking, watching other companies, and customers sharing their stories.

So how do we move from enjoying pockets of success to creating sustainable cultures of CD innovation? How do we make it sustainable? I understand that the story that you share you ending up creating apps for your own self, but how do we make it sustainable?

Matt (22:11):

That’s a good question. I've been wrestling with it over the last decade.

Once I've found this super power of low code no code, I wanted everybody to learn how to do this.

If it helped me, it's going to help others. I would say that I started by just trying to teach others what I did.

And it turns out that was insufficient. There was something missing. I later had an interaction with a gentleman from the Project Management Institute. His name is Dave Garrett. He's the Chief Strategy and Growth Officer at PMI. And he told me just kind of reinforcing what I was feeling.

He said, Dabbling is easy, scaling is hard. And I know that just reinforces what, what I just told you, but the way he put it really stuck with me. Dabbling is easy, scaling is hard, right?

Sharjeel (23:15):

Yeah

Matt (23:15):

I don't want to think of my work as just dabbling, but frankly in the scheme of what Citizen Development could be, that's what it was. It was just these individual projects that I was solving problems on and having success one at a time. So since he said that, I've really been thinking about what is it that's missing? I can't keep going and trying to do the same thing and expecting different results. Something is missing. So I've put things, this helps me think of this clearly. I put things in this paradigm of this Venn diagram.

Many people have heard of this Venn diagram. People, technology and process, those are three elements needed for a successful Citizen Development program.

People, technology and process, and you need all three. And up until PMI entered the arena for Citizen Development, only two of them existed.

Matt (24:16):

And that was the people and the technology. The people are the Citizen Developers. Those are the problem solvers. They want to make things better but they need technology to help them do that. And, so the second piece that did exist was the technology. That's the low code, No code that I told you a friend of mine turned me on to, several years ago, and it became my superpower.

But if you only have the people and the technology, you will dabble that that's all you'll do. You need that process piece to be added. And what do I mean by process piece?

The process piece is a management framework for introducing and scaling this capability across an organization. It's not enough just to have the people in tech. We need the process. After I saw that vision very clearly, I was hired by TrackVia to bring Citizen Development to our customers.

Matt (25:17):

I started to design my own Citizen Developer program, the management framework, the process piece for operating at scale. And I put a lot of work into it. But, as I was developing it, I discovered that PMI was actually doing the same thing.

They discovered that people were dabbling and that a management framework was missing from the equation for this to scale. They threw their hat in the ring and decided to develop a, a Citizen Development management framework.

And the reason they decided to do that is because they saw that using low code, no code was not a passing fad that, as you said, Sharjeel, this is the future. This is the next wave of development.

We went from waterfall to agile, and now we're going from agile to hyper agile through low code, no code.

So, I studied what PMI had put together, and frankly, it was aligned with what I was putting together, but it was way better. So, I kind of bailed on developing my own and pretty much went all in with the PMI framework. And, that's what I'm trying to teach to my customers today.

PMI Citizen Development Framework

Sharjeel (26:33):

I think you saw PMI taking over the baton and developing that. So, what's about that PMI s Citizen Development framework that has you so enamored?

Matt (26:48):

Yeah, I like that word enamored, that I am a little bit of a fanboy of PMI Citizen Development Framework.

I'll admit that. There are three things that I really like about PMI Framework and their involvement.

The first and probably most important is that they are approaching this from a technology agnostic global standard viewpoint.

So, they are not partnering with one technology like one low code, no code platform. They're setting the technology aside and saying, regardless of the technology, what does the management framework need to look like?

They are doing it as an organization that is a neutral organization and respected for developing global standards. And so the reason why I think this is so important is because PMI can uniquely create a global standard that everybody can rally around.

Matt (27:54):

If we need everybody to rally around this with the same language, the same approach so that we can advance in our collaboration, if we're all speaking different languages and have our own methodologies, it will be very difficult to grow in maturity. I think PMI is uniquely positioned to create such a standard.

The second thing that has me so enamored about PMI is Citizen Development framework is what they've produced, the products that they've put together. They are topnotch. They've developed three courses with a fourth in progress.

They've developed a Citizen Development handbook, which are 250 some pages of CD juiciness for those who are fanboys like me. And, they've established a partner program with multiple technology platforms, not just one. And I love this because this is going to make us all better. If multiple technology platforms can collaborate through a global entity like PMI, it is going to level up and improve all of our games.

Matt (29:09):

And then the last thing that they've, they've created is products are a community, a Citizen Developer community. Basically anybody who's interested in Citizen Development can go to this community page and connect with others who are interested in Citizen Development. It's a great meeting place and a great place to learn from each other.

The thing that I will probably say that I should have elaborated on, is the courses themselves. So PMI laid out their courses in terms of an introductory course, and then they grow into courses that are a little more involved.

The first course they have is called the Citizen Developer Foundation Course. It is 90 minutes, which is just enough to give you good information, but also make it so people are willing to spend the time to take that course. And what they get out of it is a vision and a language for how to talk about Citizen Development with others.

Matt (30:08):

If you can't talk with others about it, it is going to be hard to progress and hard to bring others into the fold. So that's the value of the Citizen Developer Foundation course.

The second course is their Citizen Developer Practitioner course. That's for the doers, for the people who are building apps. But remember, these are people who are not trained in coding, so they don't necessarily know best practices for building apps.

So this course teaches you not the specifics of how to use a specific low code, no code platform, but regardless of the platform that you're using, what are the best practices for building an app such as how to build an app that's intuitive. You know, everything is only two clicks away. How to build an app that is performant. It's not slow when you change pages.

Matt (31:01):

How do you build an app that is secure that, that aligns with its guardrails?

The third course is the most important because it's the one about scaling, and that's the Citizen Development Business Architect course. This is when once you make it to the adoption stage, which I'll be talking about a little later.

Once you make it to the adoption stage, you need to design an operating model. How do we, how do we scale this thing? And so that's the Citizen Development Business architect, a person that's going to be involved with designing that operating model and introducing it to the organization and making sure that it's successful. And then there's a fourth course which has yet to be developed.

Sharjeel (31:51):

That's great. I think that's a full package of knowledge and education that they're bringing in the market.

Matt (31:58):

Oh, absolutely. Yes. Yes, sir.

Citizen Development Maturity Model

Sharjeel (32:01):

Could you talk a little about the maturity model? I guess I had some discussion with you where you talked about it.

Matt (32:11):

Yes. Happy to do so, the maturity model is actually my favorite part of PMI Citizen Developer Framework.

It's my favorite because it's where the rubber hits the road. This makes scaling Citizen Development practical. It approaches Citizen Development not from the project or flavor of the month, but from a long term commitment. There are five stages in the maturity model.

First stage is discovery. Second stage is experimentation, third is adoption, fourth is scaling, and fifth is innovating.

The reason I love the discovery phase because it's basically saying, look, there are people out there who just learned the word Citizen Developer. Okay? So, if you just learned the term Citizen Developer, how could you expect an organization to commit to becoming a Citizen Development organization without first discovering and learning about it?

So the discovery phase is about one person proving to them as a non-coder that they can build an application on low code, no code successfully.

Matt (33:26):

And so they do that. They, they try it out, they try to build a simple app, but the key here is they're treating it like in an experiment. They're reflecting on what went well, what didn't go well, and they're doing this in partnership with their management and IT, and everybody's kind of observing this thing.

It's a hypothesis. We think Citizen Development could be good, but we got to check it out first, right? And so then if it goes well you move on the experimentation phase where you're basically inviting others to also discover for themselves, can they do this too with other use cases?

And then if those use cases go well, you reflect on how they went. Did they go well, did they go poorly? Was there enough evidence here to say that this is worth pursuing an adopting as an organization?

Matt (34:18):

And if there is, then you all agree to move to the adoption phase, which is where you ask this C-suite for approval to do, do this in a way that you scale it across the company.

If they approve you, then develop your operating model, your best practices, and your guardrails. That's where the Citizen Develop Business Architect comes in. Once you develop your operating model, you move to stage four, which is called scaling.

It's essentially just rolling out your operating model and continuously improving it, introducing this to more and more departments, more and more people, to the point that this becomes your culture.

And that's stage five, which is called innovating, but I wish it was called culture. Because, that's what we're trying to do, we're trying to create a cultural transformation ultimately with this movement.

Biggest Problem: Overthinking

Sharjeel (35:08):

Now that makes sense. And, you've laid out well, the maturity model. So, I'd like to pick your mind on the how do companies adopt Citizen Development.

But before I do that, could you tell me out of your head, like what are the two to three problems you continuously deal with when you try to make customers succeed with this with low code, no code?

I guess you might have observed a few patterns. Problem A, this is problem B that I've seen across companies when they try to adopt CD or low code, no code. This is the roadblock that they hit.

Matt (35:58):

I will boil this down to one problem. And it's overthinking it.

We are used to with software development, the way I described it before, you had to like get all your requirements correct up front. And so you expended so much time trying to be perfect before you took a step forward.

And so that's what we're used to because you knew you only had one shot with it. Well, this low code, no code stuff is, it's different. It is so fast that you can have an idea in your head and you can translate it to a working prototype in minutes. Literally that's possible.

But it's usually let's call it hours. The point is it is fast. So, you don't have to overthink it. And so I think this is why I like the maturity model so much, because it encourages you to get started before you've designed everything perfectly.

Matt (37:03):

I have a maturity model, or not a maturity model, but, I have a mantra that I've followed when I ran my consulting business and I adhere to it today, and it's called Think Big, Start Small Scale Fast.

It's important to think about where you're going, think about the big picture, but you don't have to have it all designed out perfectly, know where you're going, start small in a way that is manageable and allows you to establish momentum and learn something from it, and then do it again, except this time, do better than you did the last time, because you've learned from that something small.

This is in line with just the philosophy of Continuous Improvement. I guess that would be my advice. Like, don't overthink it, do it, experiment, learn, and repeat.

Sharjeel (37:54):

So, so do you, have you observed companies overthinking it?

Matt (37:59):

Oh, yes. Oh my goodness. How do I say this?

Sharjeel (38:05):

Maybe there are folks out there who are forcing them to overthink or scaring them out in their own company?

Matt (38:13):

Well, it's just new. It's something new. I think the way I would like to think of this is with a typical product adoption curve, right?

Anything that's new, you go through this product adoption curve, which starts with the innovators, which is the very few people that create this, something that's new. Then you move to the early adopters, which is also very few people that are willing to get their feet wet before this thing is proven out. And then the hard part is going to the stage three, which is the early majority.

And I would say that's where we are with Citizen Development right now. Low code, no code has jumped from the early adopters to the early majority. It's been proven out over the last 10 years. But the idea of Citizen Developers, people who are not trained in coding developing apps at scale has not jumped to the early majority.

Matt (39:12):

It's still in the early adopters phase. Now that PMI has brought this framework forward for scaling in a safe and effective way. This is what I think is going to help move us from the early adopters to the early majority because it brings in guardrails that makes people feel comfortable that I'm not taking this huge risk.

There are rules and best practices that help me do this safely. So naturally, as more and more people and companies adopt this, others who are more risk averse will be willing to step into the arena.

Advice for Adoption of Citizen Development

Sharjeel (39:51):

That's great. If you have to sum up an advice for people, for companies, for innovation managers who are out there thinking how do we adopt this CD program for our own company? What's a quick framework of advice for them?

Matt (40:10):

I'll just go back to kind of what I said earlier.

Number one, don't overthink it. You got to get started. That's the important thing. And I'll illustrate the approach that I have with what I call my Citizen Development students.

So, I've been just making people aware that I want to help them get started, remove the level of fear and be there to coach them. So, the way we get started is take that Citizen Developer Foundation course, it's only 90 minutes and it's going to give you the vision and language and confidence to be willing to try this. I was planning on having people take the practitioner course next, which is like a 10 hour commitment, nine hour commitment, including the course and the exam.

Matt (41:03):

So we're talking about more serious commitment. But here's what I learned after people took the foundation course. They were telling me, I don't want to go to the practitioner course next. I want to see what this low code, no code all about.

I want to get my hands on the technology. They said the theory that was taught in the foundation course is great, but it's like a tease, like, show me. I've never seen it. So now that I have taken the foundation course and then I give them a quick demo where I build an app in front of them in like less than 30 minutes. And that opens their eyes to go, wow, I can do that.

Then we set them up with like a free trial of the platform and have them try to build a simple app themselves, and then that gives them some context for what this theory is about. I wouldn't overthink it in terms of, oh; I got to quickly get to this adoption and scaling phase.

Just get comfortable in the discovery and experimentation phase first. Otherwise you'll overwhelm yourself with everything that you'll need to do to get to a full transformation.

Sharjeel (42:17):

That's great. Like think big, start small, scale fast, begin with discovery, and don't overthink do it and experiment and learn from it.

That's a great framework to get started. Thank you Matt for contributing your thoughts and educating us about how do to go about it. Because, for people who are ahead in the curve might think that is simple stuff, but for people who are just starting out that's not the case and they do need the tips and tricks and methodologies that people have learned over time.

Matt (42:57):

You bet, Sharjeel, thank you for having me.

I like talking about this subject and helping others wherever I can. I'd love to continue the conversation with you in the future and your guests, if they want to reach out to me I'm active on LinkedIn, so you can find me on LinkedIn, Matt Hubbard, Track Via.

Sharjeel (43:18):

Yeah. We'll be sharing your credentials soon. Thank you, Matt. Take care. Have a nice day.

‍