Jordan explores the power of prototyping in financial planning, drawing inspiration from James Dyson’s journey of creating the perfect vacuum cleaner. Jordan breaks down his prototyping process to help financial advisors become more comfortable with testing and iterating new ideas before scaling them.
Transcript
Jordan Haines:
Hello friends, and welcome to another episode of Elementality. My name is Jordan Haines, financial vital specialist here at Elements and your host for today’s show. Over the last few weeks, there has been a theme. Occurring. The theme is prototypes. For the last few weeks, I’ve presented to you prototypes that exist along your client journey, the client journey being lead generation or marketing, sales or prospecting, onboarding new clients.
I. Servicing existing clients. I presented to you ideas around monthly service calendars and quarterly service calendars. We’ve talked a lot about client perceived value and how that affects and a, uh, prospecting motion. We’ve talked in the past a lot about marketing and different ways that we can utilize smart asset leads and things like that.
Needless to say, there have been a lot of prototypes. That are presented here. Now I’m using that word in particular, prototypes because that word has taken on a lot of meaning to me lately, which I’ll define here, but lemme tell you a story. I really love learning about founders. I love learning and, and reading biographies and autobiographies.
I like learning about people’s story because I like to learn from them what worked and what didn’t. In a sense. I sometimes view other people as prototypes, um, people that have tried things and tested things that I can take and I can learn from. And one of the most formative, um, biographies I’ve listened to recently, or read recently was the founder of Dyson.
His name’s James Dyson. Um, and he has a really, really fascinating story. Um, many of you know Dyson. Dyson is the vacuum cleaner company, um, when he created Dyson in the seventies, I, I believe, or eighties, I don’t remember the exact timeframe. It started by him having a workshop in his garage and building a prototype every single day.
For about a year, and it wasn’t until that final day that he had a working prototype that he could take and scale. What’s interesting to me is that Dyson started with an idea. He had an idea for what this product could be, the perfect vacuum cleaner. I. And it took him about a year of creating tests and iterating and building prototypes to get to the point where he had one, a final version that he could then take and scale and create the company that we now know today.
Now, what’s interesting though is as I present this to people and as as I’ve explored this uh, story with other financial advisors, many of us look at that and think totally normal. ’cause we’ve seen a lot of different examples of this, of inventors that build physical products. We feel okay with this idea of prototyping with them, but in my own experience working with financial advisors over the last four or five years, I find it very difficult for financial advisors to be okay with this idea of prototyping.
And I think the reason that is, is because we are in a service business and oftentimes the, the. The result of a prototype is we are testing things on clients, and many of you listening to this might hear testing with clients and just immediately have a visceral reaction where maybe you’ve tested something with clients in the past and it didn’t go well.
Um. I think there is a way that we can actually prototype where it can be incredibly valuable. In fact, this is something that I have found I naturally do when I create I prototype. In fact, if you look at these episodes and elements, a lot of them are me just prototyping ideas. Many of these episodes are the first version of a prototype where I explore something out loud and then I go build it and I test it and I see how it works.
So today I wanna talk to you all about prototyping. And I’m gonna go through the process that I’ve created recently that has been really helpful for me as I’ve tested out a lot of the ideas that we’ve talked about in this very show. So let’s talk about what prototyping is. I use that word specifically because I think it does something to me mentally.
It makes it okay for me to have different versions. It makes it okay for me to test different things, and it makes it okay for me to not use a prototype. Many prototypes are never used. It’s not until you have the final prototype. That it is used in my experience, this is, uh, the whole sunk cost bias, right?
If we have invested a lot of our time and energy into something, oftentimes we feel like we need to do something with that. When that really is not the case in many situations, when it comes to prototyping, we shelve something, we decide we’re not going to use this, and that’s okay. So prototyping in my mind, it’s just building first version tools before you try to scale or perfect them.
In my mind, this lives perfectly in between theory. Scale. Oftentimes you can go out on LinkedIn or Twitter and you can find debates about theory. People who have built successful business often have a hard time with people who theorize. People who theorize often have a hard time with people who scale.
There’s not really this middle ground, and in my experience, prototyping is a perfect middle ground theory. It’s just a nice idea. That sounds good. It’s often brainstorming. It’s coming up with things that don’t work right. We often look at theory as frivolous and just doesn’t work right. It’s a big dream.
It’s guessing, whereas scale often is a little too rivet rigid. It’s proven, it’s polished, it’s efficient. That’s often when we use the word successful, right? When I built something successful at scale. Well, we don’t scale things out of the blue. We scale things that have been tested and tried. Scale only arrives after theory, so there has to be some middle ground.
Prototyping in my mind, is just about creating a usable, testable, early version so that you can learn from what actually works. It allows you not to invest too heavily into scale. So this is a really important part of the testing process. All of these ideas that I presented to you over the last few weeks are prototypes, and I hope that you all will test them.
And I know right away that many of the things will not be successful, and that’s okay. Some of these might not be successful at all, and that’s okay, but I’m hoping that you get comfortable with prototype prototyping. Um, this will allow you to remain relevant to your clients. It’ll allow you to move faster with less risk.
It’ll allow you to test ideas without huge investments. They give you traction before perfection. So why don’t we spend a little bit of time going through my prospect or my, sorry, my prototyping process. I’m gonna go through this framework, and obviously this is a prototype of a prototype, so I am going to likely change this over the next few months, and I’ll share along the way the things that have worked well for me.
But if you want to introduce something in your business, oftentimes it starts with sensing or feeling like there’s a job to be done. In every time I prototype, I want to articulate very clearly. This is step one, articulate very clearly what the real problem is that you’re solving. Is this client facing?
Is it internal facing? What are we actually trying to accomplish here? What do we want to get done? So for example, let’s take that monthly, uh, client service calendar. What are we trying to achieve with that? I. In my experience, it goes a lot of different directions, but most often for me personally, it’s relevance.
I want to be relevant in the minds of my client. Well, if that’s the actual job to, we’ve done the thing, the prototype that I create is gonna look a lot different. Whereas if what I’m trying to do is it’s more functional, I’m trying to see if anything changed to my client’s life, the actual thing that I create is gonna look a lot different.
Lemme give you one more example. We’ve talked about membership programs in the past. Um, downmarket service offerings, and we probably should do another episode of that soon. Basically, a subscription program that you can have clients come on, let’s say $50 a month. That’s very simple. You think about it like coaching or whatever you want, want whatever you want it to be.
In my experience, when an advisor wants to do, or a firm wants to do something like this, there are three different jobs to be done. And knowing what your job to be done is, is really important to build that membership program. Maybe your job to be done is more altruistic and neighbor in, in nature. You just want to help the people that don’t necessarily get help from a financial advisor.
Well, if that’s the case, you would create your system a little bit different. Well, what if your job to be done or your motivation here is, um, you want it to be profitable on its own? Well, that means you’re gonna create a lot of scaled systems, a lot of automation, so that you do not have to invest a lot of your time into this program.
And the final, and this is a pretty common one, this is uh, uh, our motivation at Dentist Advisors. Why we have a membership program, and that is, um, we want this to be a nurture ground for people who will be our ideal financial planning clients in the future. I. We can articulate and create that differently.
We have a clear graduation standards and things like that. So articulating your job to be done is going to be incredibly important in whatever prototype you’re creating. I highly encourage you to write it down. This often takes the most time. Getting to the bottom of what you actually want to solve is going to be really helpful.
This is gonna be helpful too, because you all just listened the last few weeks of things that I’ve created or ideas that we’ve had or seen from the financial advisors. If you hear one of those and you’re like, Ooh, that sounds great. Rather than just jump to implementing it, you should stop and say, okay, well if I do this, what problem am I solving in my business?
What problem am I solving in my client journey? Understand what job to be done is that’s going to be the most helpful thing ’cause it’s gonna dramatically change what you actually create. That’s step one. Step two is that you dream your ideal solution. Sometimes I call this my idealistic what. Right. This is what I often refer to as the magic wand face, and most often when I like my prompt here in, in understanding this, or if I’m working with someone, I will always ask, if you could wave a magic wand today, what would your perfect solution look like?
Lemme give you an example of this. At Dentist Advisors, we use Salesforce, and we’ve used Salesforce for almost a decade. Um, those of you who have used Salesforce in the past know that it’s incredibly big. There are a lot of things that you can do with it, but it’s very complex and it can easily become over-engineered.
And we are at a stage right now where we’re having to, um, peel back the onion. In ways we’ve had 10 years of building in our Salesforce motion and we either have to dramatically simplify what we have or find a new tool. And what I found myself doing is after we understood the job we’ve done, what are we trying to solve for in this prototype?
Well, I went to the our financial advisors and to our marketing team and I, and I asked ’em all, if you could wave a magic wand today, what would this tool do for you? Now, in this specific phase, we are being. Completely irrational. We are not thinking about the constraints right now. This is a time where I’m gonna highly encourage you to put aside any constraints that you have.
If you could wave a magic wand, if your time was irrelevant and resources were irrelevant. Don’t think about practicality. Don’t think about realism. I don’t want realism. I want a dream right now. If I could wave a magic wand, what would this be? The reason this matters is because this gonna is gonna get you really close to actually articulating your job.
You’ve done. You’re gonna work backwards from here. You just need to get really clear on if I could wave a magic wand, what would this thing look like? And normally what I get to is, um, sometimes there’s a big, long list of things I want it to do, and oftentimes I end up pairing that back to maybe about two to three things I.
Two to three things, things. So if I look at our CRM, what do I want it to do? I want it to track communication so I can know what’s going on in a client’s life at any given time. I want to be able to, um, get a quick snapshot of what’s happening in someone. So what is the history of someone’s situation?
And I want it to be able to, um, do some project management for me so I can track tasks or workflows or things like that. Okay, well then that means that we need to create a solution that looks blank. So wave a magic wand. What do I want this thing to do? To me that’s going to be. Step two. Step three is we get a little more realistic.
And in this stage, I’m using this prototype as a DIY, I’m gonna use that word specifically. I, in my personal life, want to build a shed in my backyard. Um, I currently, uh, work at home. I work in a guest bedroom. It’s kind of a guest bedroom office room. And, uh, if our family grows, this room is gonna become a kids’ room.
So I want another space outside of our house. I wanna build a shed. Now, the very first thing that I did when thinking about building a shed is I went out in my garage and I tried to take inventory of what I already had. I want to know what existing tools I have available. Do I need to buy new tools or do the tools I have?
Are they good enough? Um, I want to build a first version with what’s already available. Now, this often looks like, so for example, in our CRM right now, one of the things that I am, uh, one of the prototypes I’m building right now at Dentist Advisors is I want a way to, um, reach out. I. On a one-to-one basis to many people.
So I have a list of about 150 people that have contacted our, our firm over the last three to four years. And at the time, they just weren’t ready for an engagement. Now I wanna reach back out to them, but I don’t wanna do it one by one in my email. I would like to have some sort of. Uh, software, ideally that I could reach out to them.
Now, I know of a tool, it’s called SalesLoft, and SalesLoft is a great tool, but SalesLoft is meant for teams that you have at least four to five different salespeople that are gonna be using it. Now I am a solo. Right now, meaning I’m the only person in dentist advisors that is selling this, and so I don’t need four to five things.
So what I started by doing is saying, what do I have available? Well, the two tools I have available to me is we use HubSpot in marketing and we use Salesforce in our sales and CRM. So I started looking at those tools and I started asking myself, can I do this thing based off of what I had? So I started looking at one to many type of outreach features in both HubSpot and Salesforce, and I found that both of them have, um, integrated sales engagement software.
Um, one of them we’re already paying for, the other one we’re not, and I just looked at them and I saw, what do I have available? Can I build this program out based off of what I have, rather than going out and finding a third party? And what I ended up finding is the tools that I have right now are good enough.
So sometimes I call this the woodshed phase. You’re going out into the woodshed and you’re seeing what do I have available to create? What I have right now, you might listen to the things that we, we, uh, talked about the last few weeks. Maybe you’re a user elements, maybe you’re not. I would highly encourage you to start with what you have to see if you can adapt what you have to meet that need.
And if you find out, and I want you to build this, this is prototyping, right? So you are going out and you are building this thing. If upon building this thing, you don’t have a workable version. If you find out at the end of it that it’s not going to work, and it might be a few hours of work to just test and try and see if it can work, you might find that you might need something else.
That’s okay. You’re gonna shelf the first prototype that you created within your, your DIY or your woodshed, and you’re gonna go out and you’re gonna find new things. But along the way, I want you to do a couple things. One is I want you to stress test this prototype. I want you to find your test group. Do it quietly with a control group.
This might be clients that you trust or are good friends of yours. They might be peers, other advisors that you work with that you wanna test it with. But I want you to stress test whatever prototype you make. So if it’s a homegrown prototype from your woodshed, then I want you to go out and test it out with someone, and then I want you to socialize it internally with a few trusted people for feedback.
Those are the two steps in using that prototype. Don’t implement it at scale. And always have someone that you can go to, to trust and to test this. You wanna always stress test that. Stress testing, you’re gonna learn more from that than you did from just researching and trying to look at data stress, test it, learn from it.
That’s where you’ll find I need additional tools or I don’t, or this is good enough or this is not good at all. Or either need a shelf it. So this is then where you adjust, you iterate and you expand. You’re gonna improve based off of. Real reactions from people, and if necessary, you’re gonna seek out new tools and resources.
And then finally, the final decision here, you’re either going to deploy a prototype or you’re going to shelf it. This is where it gets really tough for advisors. A lot of times when we build and create a prototype, we feel like we need to do something with it. And in my experiencing, doing things for the sake of doing things is the worst thing that you can do.
You want to know if this is the right thing for you, which is why a prototype, uh, stage makes a lot of sense. There have been many times where I’ve had advisors, whether it’s implementing elements or another tool, or another program, where they will jump right into scale and they’ll treat their scale phase, like their prototype.
They’ll implement it. This is across their entire client base. I. And what they find really quickly is on that iteration process, on that deployment, they realize this is not the right tool for us. And so now they have to go and scale back. They have to take it away, they have to try over, and they’ve kind of been burned, and so they get really scared for testing things.
You need to have a test group. You need to have a prototype that you try first. Once you have a working prototype that you know works, knows, actually solves your job to be done, is close to your dream idealistic solution, then you deploy it. But that also means you’re going to shelf a lot of prototypes, and that’s okay.
It is okay to deploy time to testing and trying and realizing that it didn’t work. Not every prototype is going to scale and that is the point. So those are your options. You either deploy it or you shelf it. And that, my friends, is the end of the prototyping process. I’ve given you a few examples in here.
I think in the future as we, uh, present some of these prototypes, it’ll give us a good opportunity to really understand where are we at in the phase on this. Um, I want you to understand what the job is to be done. I want you to understand what the ideal idealistic solution. I want you to know what your constraints are and what you have available, and then I want you to test and iterate and try it.
And then you either deploy or you shelf it. So find one area that you could apply this on right now. Is there an an area of your client journey or in your business that you’re thinking, I need to make an improvement? You have this sensing, right? If you’re feeling stuck trying to build something, or perfect onboarding or review meeting or a client process, stop trying to perfect something.
Build the first version, learn fast, and then decide where to scale. So if you prototype something and you learn something from it, I’d love to hear from you. So if you take something that we’ve talked about the last few weeks and you’ve tested it and you have some thoughts and it didn’t work for you, please share that these are prototypes.
They’re not meant to be perfect. They’re not meant to be scaled right now. We will find over time as we continue to per to test and to try things. Um, we’ll be able to find it out. So, um, please feel free to reach out to me if you have any questions. You know my name Jordan Haynes. Find me on LinkedIn.
That’s where I spend a lot of my time. Or you can email us podcast@getelements.com. With that, everyone, we’ll see you next week.