February 9, 2025 • 42 mins
Ever wondered how to bridge the gap between the fast-paced world of technology and the entrepreneurial spirit? Paisley, the visionary behind Tech Translator, joins us to unravel this puzzle. Her mission is to empower entrepreneurs by demystifying complex tech jargon, making it accessible to everyone. With over a decade of experience navigating the startup ecosystem, Paisley sheds light on the traps businesses can fall into during software development and emphasizes the power of clear communication and technical literacy.
The tech landscape is shifting, especially when it comes to creating a Minimum Viable Product (MVP). Gone are the days when a simple MVP would suffice; now, robust integrations and connectivity are non-negotiable. We explore the hurdles entrepreneurs face in fitting into innovation funding programs while optimizing existing tools rather than inventing new ones. With fascinating examples like Team Care Pal struggling to integrate with electronic medical records, this episode dives into the substantial investments required for modern MVPs and the role of AI in expediting these processes.
Navigating the intricate world of software development isn't just about choosing the right tools, like low-code platforms such as Bubble.io. It's about planning, understanding, and effectively communicating project needs. Paisley shares insights on managing developer relationships, avoiding technical debt, and the importance of choosing the right programming languages for future-proofing projects. By fostering technical curiosity, listeners can enhance their collaborations and drive successful tech initiatives. Reach out to Paisley through Tech Translator's LinkedIn or directly to continue this enlightening journey!
Find Paisley at:
https://www.linkedin.com/in/paisley-churchill/
https://www.techtranslator.ca/about
Sell Me This Podcast is brought to you by the team at Deliver Digital, a Calgary-based consulting organization that guides progressive companies through the selection, implementation, and governance of key technology partnerships. Their work is transforming the technology solution and software provider landscape by helping organizations reduce costs and duplication, enhance vendor alignment, and establish sustainable operating models that empower digital progress.
If you believe you deserve more from your technology partnerships – connect with the team at:
www.deliverdigital.ca
This episode of Sell Me This Podcast was expertly edited, filmed, and produced by Laila Hobbs and Bretten Roissl of Social Launch Labs, who deliver top-tier storytelling and technical excellence. A special thanks to the entire team for their dedication to crafting compelling content that engages, connects, and inspires.
Find the team at Social Launch Labs at:
www.sociallaunchlabs.com
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
But it's also protecting yourself in the
contract If you actually justtake a step back.
Most of it is just logic-basedit's not hard.
It's actually, it's all commonsense.
This is what your developer'sdoing.
Speaker 2 (00:15):
On this episode of Sell Me this Podcast, we're
joined by Paisley, the founderof the Tech Translator.
With over a decade ofexperience in tech startups and
ecosystem building, paisley hasseen firsthand the costly
mistakes that businesses makewhen developing software.
She's on a mission to bridgethe gap between entrepreneurs
and developers, helpingbusinesses make smarter and more
informed decisions when itcomes to building custom
(00:38):
technology.
Today, she shares her insightson avoiding common pitfalls,
choosing the right developmentpartners and why understanding
tech is just as important asunderstanding finance and
business.
Let's dive in, paisley.
Thank you so much for joiningus today.
I'm going to dive right intothings.
I would love to hear a littlebit about your journey and what
(00:58):
led you to launching TechTranslator.
Speaker 1 (00:59):
Thank you so much for having me.
I'm super excited.
I feel like I'm on Call HerDaddy, which I already told you.
Speaker 2 (01:05):
Oh my goodness, I feel like this.
As I mentioned, I'm not a verygood Alex Cooper but I will try
my best here.
Speaker 1 (01:15):
So I started the Tech Translator after working in
tech for about 10 years tech andecosystem building and startups
.
So my whole career I've been inthat realm and I moved from
Calgary Economic Developmentinto custom software development
where I got to see a differentlens of how businesses grow.
And I realized that even whenthey were my clients and I was
doing everything in my power tomake the whole process easier
(01:35):
for them, they were still losingso much money and there was so
much frustration and it wasnothing that I could mitigate on
my end, despite trying to askthem all the questions and see
around the corners on theirbehalf.
It was really hard because theyjust wouldn't tell you one
thing.
And then, six months down theline, when they get their
product and their MVP andthey're doing their testing like
(01:57):
a real life scenario thathappened was somebody was like
why doesn't it work offline?
And you're like, oh my goodness, the amount of time it would
take me to explain why offlinefunctionality is a complete
rebuild.
It isn't.
You know more than I'm capableof right now, and so basically
they had to do a whole rebuild.
Speaker 2 (02:16):
Amazing.
So what does?
It sounds like you learnedquite a bit to get you to this
point.
So what exactly is the workthat Tech Translator is
embarking on?
Speaker 1 (02:24):
Yeah.
So it's a course and I also doconsulting around this as well,
but I realized that to havescalable impact, you want
something that can run in thebackground and bring people up
to speed.
So it's a course that reallystarts from the basics of
software, from a non-technicalperspective.
So we use lots of metaphorslike a house, we relate things
to Facebook and we start fromthe most simple terms.
(02:46):
You've got your front end, yourback end, your server, and
we're explaining what that is,and then we continue to evolve
and go into some of the deeperconcepts.
But everything's related backto why an entrepreneur needs to
know that and it's made reallytangible so they understand.
Okay, when I'm explaining mybusiness to my software
developer.
This is why it's important thatI say this, or I mentioned that
this is what I want.
Speaker 2 (03:06):
So do you feel that a lot of entrepreneurs, or even,
like technology, people thatembark on building out some of
these custom applications orbringing their ideas to life, do
they have a strong foundation,or do they do you think they
have a pretty flawed view ofwhat actual development
processes look like?
Speaker 1 (03:22):
Absolutely so, and I'm sure you see this a lot in
your realm as well.
But everyone walks around withthese apps that they just think
should work, and they there'snot a lot of grace when your
Facebook goes down or you can'tlog into something.
People don't really have thatunderstanding, and those are
billion dollar companies.
So then when you're buildingthem something with a $200,000
budget, they just don'tunderstand why it can't work or
(03:45):
why you can't do this.
And so in my course I reallytry to break down the man hours
that it takes to build some ofthese things, all the different
roles it takes and how that isall represented in salaries, and
that's why it's so expensive.
But even more than that is theyhave no understanding around
software concepts and businesslogic, and I find that they
defer way too much to their techteam.
(04:05):
So they're like, oh, just dowhat you think makes sense.
It doesn't actually matter whatyour project manager thinks
about your horse racing app.
Speaker 2 (04:15):
You know what I mean.
Speaker 1 (04:16):
It doesn't matter what his opinion is.
But they think everything istechnical question.
So you say do you want a pop-uphere to confirm?
Oh, I don't know.
Speaker 2 (04:25):
You let me know.
Speaker 1 (04:25):
We'll leave it to the technical people, yeah that's
not a technical question, butthey just defer so much and then
it winds up biting them in thebutt at the end because they've
deferred all of these things.
That are really businessquestions no-transcript.
Speaker 2 (04:48):
It sounds like it has permeated over and sounds like
even amplified when people arebuilding some of these custom
applications.
Speaker 1 (04:55):
Yes, and I always say the number one thing.
another number one reason yourdeveloper hates you is because
you say vague things or you askvague questions.
Can we integrate with Zoquestions?
Can we integrate with Zoho?
Can we integrate with Facebook?
What does that mean?
Of course we can.
If there's an open API, weabsolutely can do it.
Do you have the budget for it?
What do you want it to do isthe real question.
(05:17):
So my course actually evenwalks you through a framework of
understanding APIs,understanding the limitations,
because what I think some peopledon't realize when they ask
these vague questions, it's justlike lobbing something over the
fence.
You're wasting like sometimes10 hours on the tech team where
they're all spinning theirwheels trying to figure out what
you want, and then you get abill for a thousand dollars
(05:38):
because and nothing's even beencoded, because it's like that
was like 10 hours of developerstrying to figure out what you
wanted, and then at the endyou're like, oh, I don't
actually have any budget forthat.
Anyways, I was just asking.
Speaker 2 (05:50):
I agree completely.
There's so much things, so manythings that the people think
are far simpler than they areand they don't understand the
fundamental concepts behind them.
This is probably going to bethe most Canadian reference ever
, but I don't know if you'veseen the show Shits Creek.
Oh, yeah, and there's thatfamous scene where it's a
write-off.
It's the write-off.
Speaker 1 (06:07):
People will take care of it.
You're stealing my meme.
That was my meme.
Speaker 2 (06:10):
And it's kind of like that it's just connect them.
Connect to the API.
Speaker 1 (06:21):
We'll link that video to the podcast Cause.
Yeah, exactly, okay, that's sofunny.
Speaker 2 (06:24):
You've subverted me.
I don't even remember seeingthat.
Speaker 1 (06:26):
I know that's perfect Subliminal messaging, so I'll
make sure you get the credit onthat front.
Speaker 2 (06:30):
So when you so is most of the work that you're
doing with entrepreneurs, then?
Or is it with business?
Is it with both?
Like, where are you focusedthis?
Speaker 1 (06:38):
that is working with a technical team.
So oftentimes they areentrepreneurs trying to do
something completely new, but itmight be a business that's just
adopting a new technology.
Some of my clients are actuallymost of my clients are very
established professionals intheir trade or whatever subject
matter expertise they have.
They're very good at business,but then they just think all
(06:59):
they need to do is find asoftware partner and their
vision will come to life, andthey don't realize all the work
that they need to put in tounderstanding how their business
works, how they want thesoftware to work, instead of
just outlining a few vaguehigh-level features.
So it really is a spectrum, butI would say it's mostly people
who have strong subject matterexpertise already.
Speaker 2 (07:21):
So I'd like to break this into a couple of different
pieces.
So to start off with,no-transcript back a step
(07:48):
further.
Speaker 1 (07:49):
You can't even begin to search for a team and you
shouldn't even start reachingout or looking for teams until
you're so crystal clear on whatyou want.
So you need to spend hours andhours with your team.
You need to be doing so muchvalidation to understand all
your features, all the flows.
You want all the fields.
You want all the different userroles and the different edge
(08:09):
cases If you want to close thoseor not, what a minimum viable
product of that feature couldlook like, and then what your
end vision is.
Because once you understandthat full scope, then you can
decide what kind of softwareteam is right for you.
Because if you're notunderstanding the scope of your
own project, how do you know ifyou need to go to somebody a
little bit more advanced orsomebody that's more specialized
(08:29):
in prototyping, somebody thatdoes agile versus waterfall,
somebody who has a moretechnical team or somebody that
specializes in working withstartups?
It's just, there's so manythings and oftentimes even you
don't even need custom software.
Sometimes, once you do thatwhole process of understanding
your requirements, sometimes theanswer is in order to move the
(08:51):
needle, it's going to cost amillion dollars.
Or, now that I'm actuallywriting this out.
This is a way bigger projectthan just that little app that I
had in my mind and maybe it'snot in my budget and you don't
need to waste anyone's time.
So it is a really valuablequestion to say how do I pick
the right one?
But you can't even do thatuntil you have completely
understood your scope.
Speaker 2 (09:12):
There's so much work and we come across this with
some of our clients as wellwhere organizations will spend
so much time and effort to maketechnology fit their process,
technology fit their process,and sometimes if you have a
really proprietary process,that's really valid.
But sometimes a small tweak ofthe process can put you into
that custom software box or outof the custom software box into
something that's more off theshelf or into something that
(09:34):
you're talking about, and it canjust alleviate that all
together.
What are some of the othermistakes that you see
organizations or leaders makingas they're going through that
initial evaluation?
Because you've already sharedlike a hundred different things
that are really important toconsider.
What are some of the otherpitfalls you see some of these
leaders taking as they'reembarking on this initial step
of the journey?
Speaker 1 (09:55):
Yeah, I think so.
Like I said, it's notunderstanding the scope of their
project, but then it's also notunderstanding anything to do
with technology.
So I think there is.
I think we need to put theresponsibility back on the
entrepreneur or the personthat's seeking these services,
because there's so muchfrustration and so much.
This software developer screwedme over or they're out to get
(10:15):
you or they just want to makemoney, and so I think there is a
responsibility to learn alittle bit about the whole realm
as well, and you can do thatjust through YouTube and
listening to podcasts andGoogling things.
But I can't even tell you howmany people, when I worked in
custom software development,would sit in the first meeting
and you'd say something likedatabase and they'd be like
(10:36):
what's that?
Speaker 2 (10:36):
You see them frantically writing down the
notes you just gave me $200,000.
Speaker 1 (10:40):
Well, not me, but spent $200,000 and you don't
know what a database is.
That sounds like a recipe fordisaster and not having the
context.
So I would say, understandingthe process more generally,
(11:02):
understanding your project andhow that person, that technical
person, is internal or you'reoutsourcing it, that level of
communication still needs to bethere Because even if you bring
in a technical person, ifthey're not as intimate with the
business as you are, you'restill going to have to transfer
all of that knowledge to them.
Speaker 2 (11:21):
It's a real shame and I'm curious on your opinion on
this is that there's such afocus on financial literacy for
business leaders.
There's such a focus onunderstanding HR policy and laws
and regulations, and I feellike there's a big mess in terms
of this other language that'sbecoming more and more important
around being a business leader,which is the language of
technology.
(11:41):
Are you seeing the same thingsin the same way, or is this
addressed?
Some other avenue?
Speaker 1 (11:46):
I think this is a huge gap and so, even looking at
the amazing innovationecosystem we have in Alberta, we
have so much programming aroundstartups helping you understand
your client, your ICP, buildingout your validation techniques
and how you're going to get thatfeedback.
And then all of a sudden you'vedone this market research and
you have a pitch deck and thenyou're like lobbed over the
(12:07):
fence to either get grants tobuild this product but you're
not equipped to actually workwith the team, or you're lobbed
over into kind of a grossmindset, but at no point did
anyone really tell you how towork with the software
development.
And our innovation ecosystem isalso set up to really bring
(12:27):
people along the technologyreadiness levels, which I think
is a really helpful framework.
But I think the MVP is dying,and the reason I say the MVP is
dying, which is.
Speaker 2 (12:37):
I'm really excited about this because I feel like
this is some fresh content here.
Speaker 1 (12:41):
And it's nuanced.
But I think the MVP is dyingbecause the M has moved so far.
With the tools that we have.
Now there's technology foreverything.
Now there's platforms foreverything.
A lot of the big companiesoffer great free packages as
well, so it's really hard to becompetitive.
To create that next level ofvalue and to fill that ecosystem
(13:03):
gap is usually around betterworkflows or better connectivity
.
So now what I'm seeing is the Min minimum viable product
requires single sign-on.
It requires all theseintegrations.
Gone are the days where you canprototype for a few days and be
like this is my messaging app,go, use a SaaS, use Facebook
like, use different things tovalidate the concept.
(13:24):
But the majority ofentrepreneurs that I see and
work with nowadays are becomingless and less of a fit for some
of the innovation fundingprograms in Alberta because
they're not making truetechnological advancements.
They're doing great work, butthey're optimizing different
off-the-shelf things likemessaging and community building
(13:45):
and the way that they'reoptimizing data flows, but none
of that is a technical leapforward.
That's optimizing it for a newenvironment.
So that's why I say the M isnow do you have single sign-on?
Do you have this?
Because companies won't evenpilot or adopt it until it will
fit into their existing kind ofecosystem.
Speaker 2 (14:02):
And is that from a security standpoint?
Is that from a risk standpoint,a maturity standpoint?
What do you believe is drivingthat?
Speaker 1 (14:07):
It's from, I think, a fragmentation of technology
standpoint, where you see thosememes sometimes it's I'm going
to log into my Frogger and seemy jobber, and then you have to
go to Kudos and it's all thesebuzzwords and you have 90
different systems to manage yourdaily workforce.
And so I think companies havehit that inflection point where
(14:27):
there was a rush to adopt allthese cool things and then they
started realizing that none ofthem were getting used because
they didn't talk to each other.
And now they're trying tostreamline and the companies
that are coming out on top havemore integrations, and that's
where we're seeing AI is reallyable to leverage these data
points, and then, but AI can'tdo its thing unless everything's
(14:50):
connected right.
So I just think that peopledon't want a hundred fragmented
systems.
So even with my own startup, orthe startup that I'm heavily
involved with, team care pal,it's been hard to get certain
users even to pilot us becausewe don't connect with their
electronic medical record system.
So the M in that situation isway out of left field now
(15:11):
because you have to integratewith an EMR.
Speaker 2 (15:13):
And once you're talking to the EMR language and
you're connecting to some of thesecurity, the regulatory
compliance, like all of those itopens up, like those are not
$10,000 investments to get tothat point, exactly as you
probably know.
Speaker 1 (15:25):
Thankfully, the EMR that's more common in our
ecosystem is a private one.
Speaker 2 (15:29):
Okay.
Speaker 1 (15:30):
It's very hard to get into.
But yeah, it's like how do youcreate that minimum viable
product when their benchmark forminimum is?
Do you have all of these things?
Speaker 2 (15:46):
all of these things.
So, on the topic of MVPs, then,what is your take on a lot of
these different AI platforms andtools that are essentially
creating these fantastic frontends?
And I'm sure you've seen someof those demos where someone
plugs in a paragraph long promptand all of a sudden they have a
functioning application.
How is that impacting thedevelopment cycle?
Is it helpful?
Is it hindering things?
What's your perspective on someof the evolution of these
platforms and how they'redriving the creation of some of
(16:07):
these front ends?
I'll call them.
Speaker 1 (16:09):
Yeah, that's such a good question.
It's something I've been givinga lot of thought lately.
I've played around with a fewof them and they are not as
simple as they seem in thevideos ever.
For the most part, those aremore technical people.
I've even looked at Bubbleio asone of the best and most.
It's like the WordPress of nocode.
Speaker 2 (16:27):
Right.
Speaker 1 (16:27):
And you still have to understand database structures.
You still need to store theinformation somewhere and then
call it back in different fieldsand different front ends.
Like you still have to have afundamental understanding of how
databases are structured.
If-else logic, there's no wayaround that ever, because you
need to generate the prompts inthe way that speaks that
language.
So I think that those tools areamazing, but it's like the
(16:51):
advent of WordPress, where wecould all now build a website
pretty easily, but you're stillprobably going to hire somebody
to do it and it might be fasterfor them and cheaper than hard
coding it.
But I still think for most ofthose low code tools and those
prompting tools, we're stillquite far away from a true
layman's person using them, andthe only way to actually get to
(17:14):
a point where we can use them isto understand all of those
things.
But I did play around withBubble and I was trying to build
an MVP for something and justsee if I could.
Just to see if I could do it.
I was like this is a lot ofwork.
I actually don't.
I don't care enough.
I'm going to hire somebody todo this.
Speaker 2 (17:26):
I've tried the same thing myself, so with bubble,
and it's a great platform and Iwould consider myself in the
bucket of like technical enoughto be dangerous.
So I understand some of thelogic, I understand some of the
frameworks.
If you hire me to develop yourapplication, you would ran into
(17:51):
the exact same feeling where Iwas like, okay, I played around
with this for an hour onto thenext thing.
I had nowhere near afunctioning anything and it was
fun.
It was.
I learned some things, but it'snot quite as designed where you
see the person on the keynoteplug in the sentence in a very
curated environment, verycurated, there's still a process
you'll have to do.
Speaker 1 (17:59):
Ai will never, ever get to a point where you don't
have to prompt it, Like there'ssomething in your head Somehow.
You have to tell the computerthat.
But I'm also a product managerand I just I'm working with a
client right now and it's funnybecause I haven't done this type
of documentation in a few yearsand I was like really coming
back to me all the if-elsestatements and the if-thens and
(18:20):
all of these things.
But if you don't understand howto build out those decision
trees, user roles and thosetypes of things, how would you
prompt a computer to do that?
And I think that's somethingthat I really focus on in my
course is the really littledetails that you miss.
So even something like build mea newsfeed there's a thousand
(18:42):
variations of that Evensomething as simple as why
doesn't the image?
When I hard press the image,why doesn't it pop up and have a
native control to save todevice?
You had to have said that at acertain point.
Whether it's you're telling thecomputer in the mystical future
, where you can just build anapp by saying those things, or
you're telling your developer,there's a way that's built and
that's not going to be standardunless you flag those things.
Speaker 2 (19:05):
I don't think people put enough importance on the
non-sexy cool stuff in thebackground all of the data layer
, all of these things in thebackground, and it's not just an
application development.
I think the same thing comeswhen you start to have that
broader AI conversation, wherethey want all these super
interesting results at the endbut they don't want to put in
that legwork up front.
That says, okay, I'm going todo X, y and Z to map out our
(19:29):
environment.
I'm going to do these things tomap out decision trees and
logic and where things are andhow we want to communicate.
Speaker 1 (19:36):
And things still need to be structured in a way that
you can feed it to the AI, and Ithink that's what people miss.
Oh, ai can do anything it can,but what in your business has
been structured to collect thedata and attach it to the right
entities?
And, as we're talking, peoplelistening are probably already
opting out If else databases,structure, roles that probably
(19:57):
just seems so hard.
They're fast forwarding to thispart.
It's not hard, it's actually.
It's all common sense, and Ihave no formal tech training at
all.
I learned it all throughosmosis and learning on the job.
But if you actually just take astep back, most of it is just
logic based.
How would you ever report onsomething if you haven't asked
for it somewhere else?
And it's just little thingslike that.
(20:19):
Okay, you want to understandthe gender breakdown of your
users?
You need to ask genderbreakdown in the field there.
Okay, a topic that I talk aboutwith my clients and when I'm
talking to entrepreneurs is CRUD, and that's the basic of
everything, and I think thatknowledge goes so far.
So CRUD create, read, updateand delete and you need to think
(20:42):
about that all the time.
So even yesterday, I'm sittingin a meeting with a client and
it's a complete system I knownothing about.
It's a new client, I'm juststarting with them, and so I'm
blindly trying to lead thisscoping meeting.
But all systems are basicallythe same, right, and you're able
to ask probing questions.
So they said they wanted to adda field here.
Okay, so we're creating it here.
(21:04):
Now, where are all the placesit needs to be read?
Does it need to be read in thereports feature?
Does it need to be read in whatyou're sending to the client,
to their report?
Does it need to be updated?
Does it need to be deleted orarchived?
And even that framework is soimportant because so many times,
developers will build thingsand they don't give you the
(21:25):
ability to update them or deletethem, which is fair, because,
unless you asked for it,building that out for every
single thing would be.
You know, that's an enterpriselevel solution.
So I would say, typically,entrepreneurs, if you have a
$200,000 budget, you're going toget about 25%, right, but then
they're like what?
I should just be able to editthis?
(21:46):
Well, yeah, but that's a wholenother screen, that's a whole
nother pop-up, that's a wholenother API to actually update
the database and then update theplace that it's being shown
over here and all the differentthings.
I just think some of thosefundamental pieces.
It's logic, but once you have aframework, anyone that's not
technical can use that now andjust be like okay, I've created
it.
Where do I need to read it?
Do I need to update it?
(22:08):
What would that impact?
What screens do I need todelete it?
Speaker 2 (22:12):
So you bring up a really good point.
Even, I think, around peoplenot really understanding what
goes into everything, notunderstanding the effort
required to actually delivercertain components, and so if
they're starting to take youknow they let's say that they've
gone through that exercise.
They've asked some of thosequestions you identified at the
very beginning.
They found the right partner.
They're starting with buildingout something.
(22:32):
How do they get a sense of evenwhat that destination is?
I love to use the analogy noone ever wants to go on a road
trip if you don't know whereyou're going.
Speaker 1 (22:39):
Right.
Speaker 2 (22:41):
But how do they start to visualize the destination,
knowing that so many decisionshave to be made along the way?
It is an iterative process, butwhat advice would you have for
them at that stage of theirjourney?
Speaker 1 (22:51):
Like how do they understand what their product?
Needs to look like kind ofthing.
Speaker 2 (22:54):
Exactly.
Speaker 1 (22:55):
Yeah, I would say it really.
I do my best work inspreadsheets, so I just put a
tab for every feature to startwith and then I just map out
exactly what I think that willlook like and for every feature.
So, for example, in Team CarePal, it's a very featurerich app
.
I think we have nine keyfeatures that are all
interconnected, so it's quite abig app.
(23:15):
But when we're first buildingthat out, we have a tab for each
one of those features and then,when we're looking at newsfeed,
I went and I looked at 10different newsfeeds.
What do I need?
You need to define everything,right down to the looking
between Facebook and LinkedIn.
The way you even something isdifferent.
One has an option of fivedifferent emojis.
Linkedin has now adopted that,but Instagram you just like.
(23:38):
Do you want it to show just thenumber of people who have liked
?
Do you want it to show twonames and then others?
Do you want it?
What should those two names be?
Are those the last two thatliked it?
Are those?
Speaker 2 (23:51):
the highest follower count.
Speaker 1 (23:52):
There's all this logic that you need to keep
digging into.
Speaker 2 (23:55):
And sorry I was getting deep here.
No, but there's a level.
That's the kind of thing youneed to define.
Speaker 1 (23:58):
And so if you can start doing that, and then, once
you have your ideal, then scaleback and be like, okay, we
don't need five like options inthe beginning, do you know what?
And then it will slowly buildOnce you have your very end and
I keep hitting my mic, it'sgoing to sound weird.
It's okay, we've got a damagedeposit Once you have the whole
app built out, then you canstart breaking that down and
(24:20):
chunking it into version one,version two, version three,
because you're never going toget it all at once.
But then you can start to saywhat is like maybe I don't need
hard press to save at thebeginning, or I don't need some
of those native controls, andthen, once you have that, then
you take it to an app developerand then you can get really good
quotes because they'll becomparing apples to apples.
If you just take your 10features with a list, you're
(24:43):
going to be getting the mosthigh level quotes and none of
them are going to be accurateand you're probably, just due to
psychology, going to go withthe middle one, but it's
probably going to be wayunderscoped.
Speaker 2 (24:52):
And is that where you get into kind of change request
, purgatory and all of that kindof fun stuff or not so fun
stuff?
Speaker 1 (24:57):
Yes, because it goes back to thinking about create,
read, update, delete when you'rebuilding out that process map,
and a lot of times they'll sayokay, so this is where the
number one bit of frustrationcomes from.
I just paid $200,000 for thisapp and you're telling me you're
going to charge me $5,000 moreif I want to be able to go in
(25:20):
and edit the headings in theback end to show new ones on the
front end.
Yeah, because you never saidyou needed to update those, so
they were hard-coded and now weneed to have a mechanism to
update that, or it's those typesof things that they think
should just be obvious.
But it's not obvious becausedevelopers work on cards and I
even explain stuff like this inmy course.
(25:40):
Peek behind the curtain with me.
This is what your developer'sdoing.
He's assigned a card.
It says put in these headingsand this report, and it doesn't
say anything about edit it.
So he's just-.
He follows the instructions,does the instructions, and so if
you didn't say it, how wouldthey know?
But the more depth you add, themore man hours it takes and the
more the cost is.
Speaker 2 (26:02):
Yeah, and so I can see how, even from a if you
don't understand it how it couldbe frustrating.
Like 200 grand is a lot ofmoney, especially you're going
out, you're venturing and if youfeel like you're getting
something, it just comes down tocommunication or gaps in
expectation there.
The question that I keep comingback to is, as you, you went
through your spreadsheet,example, and all the different
things, the likes, the comments,et cetera, et cetera.
(26:23):
How on earth does someone evenknow the right questions to ask,
to be?
And maybe the answer is yourcourse.
But like there's so manyquestions and so many variables
that it sounds like are reallyimportant to consider in advance
of approaching these vendors.
How do, how does someone evenpossibly get that list to know?
Where do I have the rightquestions?
Speaker 1 (26:44):
We are living in the future.
Speaker 2 (26:46):
We have chat GPT in our pockets.
Speaker 1 (26:48):
I think there's a couple of things you can do.
Is there's some good promptsyou can do on ChatGPT?
If you're saying I want tobuild a newsfeed, give me so.
Once you've looked at all thedifferent variables and you've
tried to define as much as youcan for logic, then ask ChatGPT.
Give me 10 edge cases aroundhow users might use.
And an edge case for those whodon't know is something that
(27:10):
doesn't follow the desired userpath.
And an example of on Facebookthat might be somebody uploading
a video that's too big.
They would have kind ofparameters of how big the video
can be and the edge case wouldbe somebody tries to upload a
19-hour video and it throws anerror, or maybe the site crashes
because it doesn't even knowhow to handle it.
You want to understand edgecases and see if you want to
(27:33):
close them, like, maybe in thatcase it just does a pop-up Sorry
, your video's too big.
But you might also just want to.
There's different ways that youcould address those.
Basically, I would say go intoChatGPT, tell them a little bit
about your feature and then askit for edge cases.
Ask ChatGPT.
What are some considerations Ishould have on the UI?
What are some considerations Ishould have in different pieces
(27:55):
of this and it'll just start togive you some ideas and I've
used that pretty successfully.
Speaker 2 (28:00):
And I didn't even think about that, but the
availability of a lot of theseAI tools can be an ally on your
side as you're working throughthese different processes.
Speaker 1 (28:08):
Yeah.
Speaker 2 (28:09):
So then when you start to actually work with some
of these developers, you hearso many horror stories of the
first couple of weeks were great, it seemed like we were on the
same page.
Then all of a sudden thingsstart to go downhill really
quickly.
What are some of the commonmistakes founders or business
folks or IT folks make as theystart to work through these
projects and kind of start tobring them to fruition?
Speaker 1 (28:32):
projects and kind of start to bring them to fruition.
Yeah, they're not providingenough clarity, which I think
I'd beat to death, but it's justagain not saying what do you
think Do what you think makessense, because it'll never make
sense.
They do not know your businessand I have so many funny
examples of that.
But, yeah, it's the clarity, butit's also protecting yourself
in the contract and it is havingsomebody, I would say, on your
roster and even introducing thisat a very early stage to tell
(28:53):
the software company, whenyou're doing that contract is I
want the right to have somebodyto come in and audit this and
also understand the level ofdocumentation that they're going
to do and have some of thatwritten in the contract, because
documentation is not standardand I think more people think it
is standard but it takes a lotof time to document, time that
(29:13):
they need to charge you for.
So you want to have in yourcontract level of documentation
that will be provided andsometimes it's none because you
don't have the budget for it andyou're just moving fast and
agile.
But you also want to havethings like where the code needs
to be stored and what languageneeds to be used and what
framework needs to be used andwhat language needs to be used.
(29:33):
And what framework needs to beused Because sometimes software
development companies willrecycle old projects and you'll
end up starting a project with alot of technical debt and
you'll start seeing bugs rightaway.
Speaker 2 (29:42):
I didn't even know that was a possibility.
People would steal someone'scode from someone else or an old
project and just to get a headstart.
Is that kind of a?
Speaker 1 (29:48):
It's a pretty common practice to use libraries.
So let's say you're eitherusing a publicly available
library to build a chat featureor you've built so many chat
features that you have thisframework that you're using
constantly.
But if you have two kind ofsimilar projects, you might say,
hey, we could reuse a lot ofthat old structure and slap new
UI on it, which is actuallytotally fine as long as the code
(30:09):
base has been updated.
It's when they're trying toresell something that was built
two years ago on a lowerframework and now you're going
to be adopting a lot of thattechnical debt.
So have framework numbers inthere, have the language that
needs to be coded, have thatyou're allowed to do spot checks
.
Because the other thing isoftentimes companies won't allow
you into your AWS for a goodreason because if you mess
(30:30):
anything up, they have to payfor it, or they have to fix it
and you'll need to pay for it,and that just creates a
difficult relationship, some ofthat friction?
Speaker 2 (30:40):
I've been asked this question before and I do not
know the answer to it.
Do the languages, like I knowthey have, use cases, but how do
they matter as a technicalfounder or a IT person?
Does it matter to them whatlanguage they use?
Or how does someone even makethat choice?
Speaker 1 (30:51):
It shouldn't really matter what language is being
used, as long as it's a popularlanguage that you can find
somebody to take it over.
So they're in customdevelopment.
There's some more prominentlanguages and there's gonna be
some really obscure or olderlanguages, and they're pretty
much all fine unless your systemis like a mega system.
Some are gonna be a little bitmore efficient for certain
(31:13):
things.
I'm not the most technicalperson in the world, but there's
certain things that are justthe way you write.
That code is a little bit moreefficient and it's faster, but
it's so nominal it doesn'treally matter unless you're
Google or Facebook.
But those systems are so oldSome of them are written on
really old languages anyways.
But yeah, it doesn't reallymatter.
But you should do a quickgoogle search to understand are
other people using this language?
(31:33):
Because if you ever can't staywith that company, you need to
find someone to take it over,and I have found some clients
who have gone with companiesthat promise they can build
faster than their competitorsbecause they use their own
internal framework.
That unless you're taking avery calculated risk because
they're going to do it for socheap that you don't mind
redoing it, stay away from thatbecause you're not a very
calculated risk, because they'regoing to do it for so cheap
that you don't mind redoing it.
(31:54):
Stay away from that, becauseyou're not going to be able to
find a new developer to take itover and they might own the
rights to that platform and youmight not be able to take it
with you.
Speaker 2 (32:03):
When I was in a conversation with someone the
other day and I'm really curiouson your perspective on this
around that idea of buildcheaply, test the market and
then rebuild.
But there's so many actualpractical challenges with that
approach around.
Let's say you've onboarded acouple of users and test users.
People are giving feedback andall of a sudden they're starting
to pay you for it.
It's not quite as simple aswe're going to take it down and
(32:24):
just hold on while we spin upthe new one.
Speaker 1 (32:28):
Yeah, that is a strategy that Team CarePal tried
, and I think it's exactly whatyou're saying is, we had thought
we'll rebuild.
We went with a smaller company.
They've been great, but we justthought we might outgrow them
and we'll do a MVP and thenwe'll move on.
But, exactly like you said,you're, you have a lot of
customers on board, you have alot of data in there and the
(32:48):
customers are constantly askingfor new features.
So even though you think, okay,I'm done, my MVP was cheap, you
can't actually usually sellyour MVP.
So you're constantly makingchanges to adjust to the market
and to adapt to user feedbackand all of a sudden, this trial
system is very expensive andhard to get away from and
(33:10):
usually it's going to take yousix months to build that new
system.
So either you have to stopdevelopment on your new system
completely waiting for the newone to be built, or you're
literally throwing away moneybecause this client says I can't
use this unless you do thisthing and everything's a couple
thousand dollars.
Speaker 2 (33:25):
Yeah, everything costs money and everything costs
time.
Yeah, so that brings me into mynext question, which is really
around the sustainment ofeverything.
So you have these partners thathave been along with you for
the ride, but are most of theengagements that you're seeing
people set up for these types ofprojects do they have a finish
line?
Or when do they start totransition into maintenance mode
?
Or do they never transitioninto maintenance mode?
Speaker 1 (33:47):
Usually the end game for the software company is to
get a maintenance contractbecause that's often how they
make their money.
Those builds can have reallylow margins because things
always go wrong and so theinitial build can be lower
margin for them.
But if they can get a lot ofmaintenance clients, that's
helpful for them to have thatreoccurring revenue.
I often see that's where therelationships devolve, because
(34:11):
everything is a change order andthose hours are used up very
quickly with bugs and a lot offounders are like you built this
.
I paid you to build it and I'mpaying you to build to fix the
bugs.
And my friend Seth and he's thepresident of Corridor, a custom
software shop, he's I wouldn'thave a job if code didn't have
bugs.
I wish we could build it and itwould have no bugs forever, but
(34:31):
then you wouldn't need softwaredevelopers, really right?
You also have to remember thatyour product is living in a
living environment, and so ifit's connected to APIs, or if
your phone updates, or if thebrowser updates, all of these
things could cause bugs.
Speaker 2 (34:46):
Right, it's not just your system, it's all of these
things that are around it thatconnect into it that the
information goes back and forth.
Yeah, it's all of these thingsthat are around it, that connect
into it, that the informationgoes back and forth, and it's.
Yeah, there's no longer, andI'd be.
I'm sure there are manyexamples of this, but there's
not too many applications thatjust stand by themselves, that
don't talk to anything elseexactly like your calculator app
is one that's.
That's about it and even I don't.
The new ios update there's a.
(35:07):
It's much more advanced than itwas as well, which is very
exciting, yeah, I that.
Speaker 1 (35:11):
I can't believe they kept that calculator app the
same for as long as they did.
Speaker 2 (35:14):
Yeah, very limited upkeep on that one.
Speaker 1 (35:17):
Yeah, so I definitely see.
If the relationship moves intothis maintenance mode, that's
when there starts to be evenmore friction, because you're
like this should have been partof the initial build, I
shouldn't have to pay for this.
But you do have to remember allof that is attached to man
hours.
The other thing is the softwarecompany wants to make you happy
.
So if you're giving them, ifyou're asking them for these
(35:38):
changes that are out of scope,they might give you a few of
them.
But then when they see thespend hit this threshold, even
if it was in scope, the answerhas to be no or they have to
recoup it at some point.
So sometimes they give youthese little things along the
way and then a mistake isactually their fault and it's
hard to get them to pay for itbecause it's no matter who says
(36:00):
yeah we like.
They're a business right.
Speaker 2 (36:02):
And I've seen this as well in a lot of kind of larger
corporate service agreementswhere you know, sometimes people
as well do in the right thingsand inadvertently reinforce the
wrong behaviors and so theymight them saying yes to these
things out of the goodness oftheir heart.
They have a great relationship.
They want to do the right thingfor the customer Sometimes
leads them down these weird pathwhere either it creates this
weird expectation to what you'resaying they take a shortcut
(36:24):
because they're doing it outsideof the process, so maybe they
don't QA it properly or maybethey don't take some of the
steps.
That things would usually happenwhen it goes through this usual
rigor, but sometimes, in doingthe right things, it actually
creates these horrible outcomes.
Speaker 1 (36:38):
Yes, absolutely.
And yeah it's hard to explainthat to a cash strap founder
that you, you asked for this.
I gave it to you.
That cost me 30 extra hours ofdev time.
Now that you're saying this isthe thing you really need, it's
yeah, you've used up yourgoodwill.
And then the founders Iwouldn't have done that if.
Speaker 2 (36:58):
I knew.
Speaker 1 (36:58):
And it's.
We wouldn't have done that ifwe knew we were just trying to
be nice.
Speaker 2 (37:01):
Yeah, so I want to pivot a tiny bit towards Pivot.
Speaker 1 (37:06):
Yeah, like that, ross .
Speaker 2 (37:08):
I'm afraid to make meme references, because I feel
like I'm going to steal one ofyour memes inadvertently again
here.
Speaker 1 (37:12):
I do use the Ross one a lot, me and the founder of
CarePal.
Cindy, send it to each otherall the time, that's well used
it's in your favorites therejust to copy and paste.
Speaker 2 (37:22):
A lot of the work that we do and a lot of the
people listening are on thecorporate side of things, and so
I know you're incrediblyinvolved in the startup
community, the innovationcommunity here in Calgary, and I
have this love for the startupscene in Calgary and this
innovation community.
It's incredibly inspiring.
It's quick, moving, things arehappening, there's an energy
around it and I feel likesometimes there's such a
(37:44):
contrast to the corporate side.
I don't know if you see it thesame way, but do you do most of
your work on the startup side orare you working at all with
kind of corporate customers thatare trying to adapt some of
those more agile, startup-esqueprinciples?
Speaker 1 (37:59):
Yeah, most of my clients are startups or they're
mid-sized companies that areadopting a new product.
I usually catch people asthey're building out a new
product, but I do productmanagement as well for larger
companies, so I have dipped mytoes in that water, but I think
it is so needed and so I thinkit's the same principles that if
(38:23):
you're a mid-level manager, ifyou're an HR person, if you're
if you're anybody working in atech company, you should
understand these terms as welland you should understand the
basics of software, becauseeverything is a software company
nowadays, or you might have adev team, and I think these
principles are the sameeverywhere.
And I think I mentioned to youthat somebody on LinkedIn
(38:46):
commented and I don't thinkthey're a startup, but he was
saying oh, hearing you say frontend and back end.
That was the first time I'veheard those explained.
And then the next day somebodyasked him to hire a front-end
and back-end software developer.
So he actually knew what thatmeant.
And it just shows thedisconnect that a lot of these
people who have very high-leveljobs in these organizations
might not know those basic terms.
(39:07):
And it's what could we do andhow much more efficient could
those companies be if there wasjust more understanding.
Speaker 2 (39:13):
I could not agree more was just more understanding
.
I could not agree more.
Most of the work that I see anda lot of the innovation that I
see being driven in some ofthese larger corporate
environments isn't coming fromIT.
It's coming from theirmarketing, it's coming from
their revenue engines, it'scoming from HR and operations
and all the parts of thebusiness and sometimes and I
probably shouldn't say this, butsometimes IT is the one
actually slowing things down.
(39:50):
And so I agree with youwholeheartedly that this
language of how do you make someof these ideas come to life in
a technical capacity is alanguage that needs to be
learned, not just in IT, notjust from the technical founder,
but it needs to be like French.
It needs to become part of thecommon vernacular across
organizations, because they needto be able to communicate in
ways that can make theirorganizations digitally forward
100% and it's just like it's2025.
Speaker 1 (40:04):
We all should know these terms.
Like you said, that should becommon and they should also
understand the players on eachof the software team.
I think that would be a reallygreat step forward.
My dream would be for everybodythat works in any sort of tech
company, no matter your rolesales or HR I want you to know
what the nine or 10 common rolesare in a software company.
(40:25):
I want you to understand thesalaries ranges of these people.
I want you to understand howmuch of their time goes into
building a product, and then theprocess and some of the basics
of how software works, becausethat's where you get to build
some of this empathy andunderstand why things are taking
so long, why they're soexpensive.
It's not just lobbing thingsover the fence to your product
(40:46):
team.
It's like having that truecollaboration and empathy.
Speaker 2 (40:49):
Love it.
I feel like we probably couldtalk for another four or five
hours.
This entire conversation zoomedby and I just I want to thank
you so much for coming today.
Before we leave, there's kindof two things I want to dive
into.
One final word of advice foranyone listening outside of Take
your Course, which I feel likeis implied, but a final word of
advice for some of these folksthat are interested in learning
(41:10):
more about this.
Speaker 1 (41:12):
Be super curious.
Leverage ChatGPT and other LLMs.
You can ask so many goodquestions.
Google top 10 software terms.
Throw them into ChatGPT.
Ask it to give you a metaphor.
Ask it to bring it down to agrade two level.
There's so many ways that youcan get this information for
free and just be really curious.
(41:32):
If you hear a term, google it.
If you don't quite understandit, ask someone.
I just think the moretechnically literate we are, the
more we can all work togetherbetter.
Speaker 2 (41:40):
Amazing.
And if people want to becomeeven more technically literate
and they want to either connectwith you, learn more about you
or your course, what's the bestway to get in touch with you?
Speaker 1 (41:48):
You can follow my LinkedIn page, the Tech
Translator, or just send me amessage.
Reach out to me directly.
I'd be happy to chat.
Speaker 2 (41:54):
Awesome.
Well, thank you so much,paisley, and really appreciate
the time today.
Thank you, and this was a blast.
Thank you so much yeah.
Speaker 1 (42:00):
Thanks for having me.
But it's also protecting yourself in the
contract If you actually justtake a step back.
Most of it is just logic-basedit's not hard.
It's actually, it's all commonsense.
This is what your developer'sdoing.
Speaker 2 (00:15):
On this episode of Sell Me this Podcast, we're
joined by Paisley, the founderof the Tech Translator.
With over a decade ofexperience in tech startups and
ecosystem building, paisley hasseen firsthand the costly
mistakes that businesses makewhen developing software.
She's on a mission to bridgethe gap between entrepreneurs
and developers, helpingbusinesses make smarter and more
informed decisions when itcomes to building custom
(00:38):
technology.
Today, she shares her insightson avoiding common pitfalls,
choosing the right developmentpartners and why understanding
tech is just as important asunderstanding finance and
business.
Let's dive in, paisley.
Thank you so much for joiningus today.
I'm going to dive right intothings.
I would love to hear a littlebit about your journey and what
(00:58):
led you to launching TechTranslator.
Speaker 1 (00:59):
Thank you so much for having me.
I'm super excited.
I feel like I'm on Call HerDaddy, which I already told you.
Speaker 2 (01:05):
Oh my goodness, I feel like this.
As I mentioned, I'm not a verygood Alex Cooper but I will try
my best here.
Speaker 1 (01:15):
So I started the Tech Translator after working in
tech for about 10 years tech andecosystem building and startups
.
So my whole career I've been inthat realm and I moved from
Calgary Economic Developmentinto custom software development
where I got to see a differentlens of how businesses grow.
And I realized that even whenthey were my clients and I was
doing everything in my power tomake the whole process easier
(01:35):
for them, they were still losingso much money and there was so
much frustration and it wasnothing that I could mitigate on
my end, despite trying to askthem all the questions and see
around the corners on theirbehalf.
It was really hard because theyjust wouldn't tell you one
thing.
And then, six months down theline, when they get their
product and their MVP andthey're doing their testing like
(01:57):
a real life scenario thathappened was somebody was like
why doesn't it work offline?
And you're like, oh my goodness, the amount of time it would
take me to explain why offlinefunctionality is a complete
rebuild.
It isn't.
You know more than I'm capableof right now, and so basically
they had to do a whole rebuild.
Speaker 2 (02:16):
Amazing.
So what does?
It sounds like you learnedquite a bit to get you to this
point.
So what exactly is the workthat Tech Translator is
embarking on?
Speaker 1 (02:24):
Yeah.
So it's a course and I also doconsulting around this as well,
but I realized that to havescalable impact, you want
something that can run in thebackground and bring people up
to speed.
So it's a course that reallystarts from the basics of
software, from a non-technicalperspective.
So we use lots of metaphorslike a house, we relate things
to Facebook and we start fromthe most simple terms.
(02:46):
You've got your front end, yourback end, your server, and
we're explaining what that is,and then we continue to evolve
and go into some of the deeperconcepts.
But everything's related backto why an entrepreneur needs to
know that and it's made reallytangible so they understand.
Okay, when I'm explaining mybusiness to my software
developer.
This is why it's important thatI say this, or I mentioned that
this is what I want.
Speaker 2 (03:06):
So do you feel that a lot of entrepreneurs, or even,
like technology, people thatembark on building out some of
these custom applications orbringing their ideas to life, do
they have a strong foundation,or do they do you think they
have a pretty flawed view ofwhat actual development
processes look like?
Speaker 1 (03:22):
Absolutely so, and I'm sure you see this a lot in
your realm as well.
But everyone walks around withthese apps that they just think
should work, and they there'snot a lot of grace when your
Facebook goes down or you can'tlog into something.
People don't really have thatunderstanding, and those are
billion dollar companies.
So then when you're buildingthem something with a $200,000
budget, they just don'tunderstand why it can't work or
(03:45):
why you can't do this.
And so in my course I reallytry to break down the man hours
that it takes to build some ofthese things, all the different
roles it takes and how that isall represented in salaries, and
that's why it's so expensive.
But even more than that is theyhave no understanding around
software concepts and businesslogic, and I find that they
defer way too much to their techteam.
(04:05):
So they're like, oh, just dowhat you think makes sense.
It doesn't actually matter whatyour project manager thinks
about your horse racing app.
Speaker 2 (04:15):
You know what I mean.
Speaker 1 (04:16):
It doesn't matter what his opinion is.
But they think everything istechnical question.
So you say do you want a pop-uphere to confirm?
Oh, I don't know.
Speaker 2 (04:25):
You let me know.
Speaker 1 (04:25):
We'll leave it to the technical people, yeah that's
not a technical question, butthey just defer so much and then
it winds up biting them in thebutt at the end because they've
deferred all of these things.
That are really businessquestions no-transcript.
Speaker 2 (04:48):
It sounds like it has permeated over and sounds like
even amplified when people arebuilding some of these custom
applications.
Speaker 1 (04:55):
Yes, and I always say the number one thing.
another number one reason yourdeveloper hates you is because
you say vague things or you askvague questions.
Can we integrate with Zoquestions?
Can we integrate with Zoho?
Can we integrate with Facebook?
What does that mean?
Of course we can.
If there's an open API, weabsolutely can do it.
Do you have the budget for it?
What do you want it to do isthe real question.
(05:17):
So my course actually evenwalks you through a framework of
understanding APIs,understanding the limitations,
because what I think some peopledon't realize when they ask
these vague questions, it's justlike lobbing something over the
fence.
You're wasting like sometimes10 hours on the tech team where
they're all spinning theirwheels trying to figure out what
you want, and then you get abill for a thousand dollars
(05:38):
because and nothing's even beencoded, because it's like that
was like 10 hours of developerstrying to figure out what you
wanted, and then at the endyou're like, oh, I don't
actually have any budget forthat.
Anyways, I was just asking.
Speaker 2 (05:50):
I agree completely.
There's so much things, so manythings that the people think
are far simpler than they areand they don't understand the
fundamental concepts behind them.
This is probably going to bethe most Canadian reference ever
, but I don't know if you'veseen the show Shits Creek.
Oh, yeah, and there's thatfamous scene where it's a
write-off.
It's the write-off.
Speaker 1 (06:07):
People will take care of it.
You're stealing my meme.
That was my meme.
Speaker 2 (06:10):
And it's kind of like that it's just connect them.
Connect to the API.
Speaker 1 (06:21):
We'll link that video to the podcast Cause.
Yeah, exactly, okay, that's sofunny.
Speaker 2 (06:24):
You've subverted me.
I don't even remember seeingthat.
Speaker 1 (06:26):
I know that's perfect Subliminal messaging, so I'll
make sure you get the credit onthat front.
Speaker 2 (06:30):
So when you so is most of the work that you're
doing with entrepreneurs, then?
Or is it with business?
Is it with both?
Like, where are you focusedthis?
Speaker 1 (06:38):
that is working with a technical team.
So oftentimes they areentrepreneurs trying to do
something completely new, but itmight be a business that's just
adopting a new technology.
Some of my clients are actuallymost of my clients are very
established professionals intheir trade or whatever subject
matter expertise they have.
They're very good at business,but then they just think all
(06:59):
they need to do is find asoftware partner and their
vision will come to life, andthey don't realize all the work
that they need to put in tounderstanding how their business
works, how they want thesoftware to work, instead of
just outlining a few vaguehigh-level features.
So it really is a spectrum, butI would say it's mostly people
who have strong subject matterexpertise already.
Speaker 2 (07:21):
So I'd like to break this into a couple of different
pieces.
So to start off with,no-transcript back a step
(07:48):
further.
Speaker 1 (07:49):
You can't even begin to search for a team and you
shouldn't even start reachingout or looking for teams until
you're so crystal clear on whatyou want.
So you need to spend hours andhours with your team.
You need to be doing so muchvalidation to understand all
your features, all the flows.
You want all the fields.
You want all the different userroles and the different edge
(08:09):
cases If you want to close thoseor not, what a minimum viable
product of that feature couldlook like, and then what your
end vision is.
Because once you understandthat full scope, then you can
decide what kind of softwareteam is right for you.
Because if you're notunderstanding the scope of your
own project, how do you know ifyou need to go to somebody a
little bit more advanced orsomebody that's more specialized
(08:29):
in prototyping, somebody thatdoes agile versus waterfall,
somebody who has a moretechnical team or somebody that
specializes in working withstartups?
It's just, there's so manythings and oftentimes even you
don't even need custom software.
Sometimes, once you do thatwhole process of understanding
your requirements, sometimes theanswer is in order to move the
(08:51):
needle, it's going to cost amillion dollars.
Or, now that I'm actuallywriting this out.
This is a way bigger projectthan just that little app that I
had in my mind and maybe it'snot in my budget and you don't
need to waste anyone's time.
So it is a really valuablequestion to say how do I pick
the right one?
But you can't even do thatuntil you have completely
understood your scope.
Speaker 2 (09:12):
There's so much work and we come across this with
some of our clients as wellwhere organizations will spend
so much time and effort to maketechnology fit their process,
technology fit their process,and sometimes if you have a
really proprietary process,that's really valid.
But sometimes a small tweak ofthe process can put you into
that custom software box or outof the custom software box into
something that's more off theshelf or into something that
(09:34):
you're talking about, and it canjust alleviate that all
together.
What are some of the othermistakes that you see
organizations or leaders makingas they're going through that
initial evaluation?
Because you've already sharedlike a hundred different things
that are really important toconsider.
What are some of the otherpitfalls you see some of these
leaders taking as they'reembarking on this initial step
of the journey?
Speaker 1 (09:55):
Yeah, I think so.
Like I said, it's notunderstanding the scope of their
project, but then it's also notunderstanding anything to do
with technology.
So I think there is.
I think we need to put theresponsibility back on the
entrepreneur or the personthat's seeking these services,
because there's so muchfrustration and so much.
This software developer screwedme over or they're out to get
(10:15):
you or they just want to makemoney, and so I think there is a
responsibility to learn alittle bit about the whole realm
as well, and you can do thatjust through YouTube and
listening to podcasts andGoogling things.
But I can't even tell you howmany people, when I worked in
custom software development,would sit in the first meeting
and you'd say something likedatabase and they'd be like
(10:36):
what's that?
Speaker 2 (10:36):
You see them frantically writing down the
notes you just gave me $200,000.
Speaker 1 (10:40):
Well, not me, but spent $200,000 and you don't
know what a database is.
That sounds like a recipe fordisaster and not having the
context.
So I would say, understandingthe process more generally,
(11:02):
understanding your project andhow that person, that technical
person, is internal or you'reoutsourcing it, that level of
communication still needs to bethere Because even if you bring
in a technical person, ifthey're not as intimate with the
business as you are, you'restill going to have to transfer
all of that knowledge to them.
Speaker 2 (11:21):
It's a real shame and I'm curious on your opinion on
this is that there's such afocus on financial literacy for
business leaders.
There's such a focus onunderstanding HR policy and laws
and regulations, and I feellike there's a big mess in terms
of this other language that'sbecoming more and more important
around being a business leader,which is the language of
technology.
(11:41):
Are you seeing the same thingsin the same way, or is this
addressed?
Some other avenue?
Speaker 1 (11:46):
I think this is a huge gap and so, even looking at
the amazing innovationecosystem we have in Alberta, we
have so much programming aroundstartups helping you understand
your client, your ICP, buildingout your validation techniques
and how you're going to get thatfeedback.
And then all of a sudden you'vedone this market research and
you have a pitch deck and thenyou're like lobbed over the
(12:07):
fence to either get grants tobuild this product but you're
not equipped to actually workwith the team, or you're lobbed
over into kind of a grossmindset, but at no point did
anyone really tell you how towork with the software
development.
And our innovation ecosystem isalso set up to really bring
(12:27):
people along the technologyreadiness levels, which I think
is a really helpful framework.
But I think the MVP is dying,and the reason I say the MVP is
dying, which is.
Speaker 2 (12:37):
I'm really excited about this because I feel like
this is some fresh content here.
Speaker 1 (12:41):
And it's nuanced.
But I think the MVP is dyingbecause the M has moved so far.
With the tools that we have.
Now there's technology foreverything.
Now there's platforms foreverything.
A lot of the big companiesoffer great free packages as
well, so it's really hard to becompetitive.
To create that next level ofvalue and to fill that ecosystem
(13:03):
gap is usually around betterworkflows or better connectivity
.
So now what I'm seeing is the Min minimum viable product
requires single sign-on.
It requires all theseintegrations.
Gone are the days where you canprototype for a few days and be
like this is my messaging app,go, use a SaaS, use Facebook
like, use different things tovalidate the concept.
(13:24):
But the majority ofentrepreneurs that I see and
work with nowadays are becomingless and less of a fit for some
of the innovation fundingprograms in Alberta because
they're not making truetechnological advancements.
They're doing great work, butthey're optimizing different
off-the-shelf things likemessaging and community building
(13:45):
and the way that they'reoptimizing data flows, but none
of that is a technical leapforward.
That's optimizing it for a newenvironment.
So that's why I say the M isnow do you have single sign-on?
Do you have this?
Because companies won't evenpilot or adopt it until it will
fit into their existing kind ofecosystem.
Speaker 2 (14:02):
And is that from a security standpoint?
Is that from a risk standpoint,a maturity standpoint?
What do you believe is drivingthat?
Speaker 1 (14:07):
It's from, I think, a fragmentation of technology
standpoint, where you see thosememes sometimes it's I'm going
to log into my Frogger and seemy jobber, and then you have to
go to Kudos and it's all thesebuzzwords and you have 90
different systems to manage yourdaily workforce.
And so I think companies havehit that inflection point where
(14:27):
there was a rush to adopt allthese cool things and then they
started realizing that none ofthem were getting used because
they didn't talk to each other.
And now they're trying tostreamline and the companies
that are coming out on top havemore integrations, and that's
where we're seeing AI is reallyable to leverage these data
points, and then, but AI can'tdo its thing unless everything's
(14:50):
connected right.
So I just think that peopledon't want a hundred fragmented
systems.
So even with my own startup, orthe startup that I'm heavily
involved with, team care pal,it's been hard to get certain
users even to pilot us becausewe don't connect with their
electronic medical record system.
So the M in that situation isway out of left field now
(15:11):
because you have to integratewith an EMR.
Speaker 2 (15:13):
And once you're talking to the EMR language and
you're connecting to some of thesecurity, the regulatory
compliance, like all of those itopens up, like those are not
$10,000 investments to get tothat point, exactly as you
probably know.
Speaker 1 (15:25):
Thankfully, the EMR that's more common in our
ecosystem is a private one.
Speaker 2 (15:29):
Okay.
Speaker 1 (15:30):
It's very hard to get into.
But yeah, it's like how do youcreate that minimum viable
product when their benchmark forminimum is?
Do you have all of these things?
Speaker 2 (15:46):
all of these things.
So, on the topic of MVPs, then,what is your take on a lot of
these different AI platforms andtools that are essentially
creating these fantastic frontends?
And I'm sure you've seen someof those demos where someone
plugs in a paragraph long promptand all of a sudden they have a
functioning application.
How is that impacting thedevelopment cycle?
Is it helpful?
Is it hindering things?
What's your perspective on someof the evolution of these
platforms and how they'redriving the creation of some of
(16:07):
these front ends?
I'll call them.
Speaker 1 (16:09):
Yeah, that's such a good question.
It's something I've been givinga lot of thought lately.
I've played around with a fewof them and they are not as
simple as they seem in thevideos ever.
For the most part, those aremore technical people.
I've even looked at Bubbleio asone of the best and most.
It's like the WordPress of nocode.
Speaker 2 (16:27):
Right.
Speaker 1 (16:27):
And you still have to understand database structures.
You still need to store theinformation somewhere and then
call it back in different fieldsand different front ends.
Like you still have to have afundamental understanding of how
databases are structured.
If-else logic, there's no wayaround that ever, because you
need to generate the prompts inthe way that speaks that
language.
So I think that those tools areamazing, but it's like the
(16:51):
advent of WordPress, where wecould all now build a website
pretty easily, but you're stillprobably going to hire somebody
to do it and it might be fasterfor them and cheaper than hard
coding it.
But I still think for most ofthose low code tools and those
prompting tools, we're stillquite far away from a true
layman's person using them, andthe only way to actually get to
(17:14):
a point where we can use them isto understand all of those
things.
But I did play around withBubble and I was trying to build
an MVP for something and justsee if I could.
Just to see if I could do it.
I was like this is a lot ofwork.
I actually don't.
I don't care enough.
I'm going to hire somebody todo this.
Speaker 2 (17:26):
I've tried the same thing myself, so with bubble,
and it's a great platform and Iwould consider myself in the
bucket of like technical enoughto be dangerous.
So I understand some of thelogic, I understand some of the
frameworks.
If you hire me to develop yourapplication, you would ran into
(17:51):
the exact same feeling where Iwas like, okay, I played around
with this for an hour onto thenext thing.
I had nowhere near afunctioning anything and it was
fun.
It was.
I learned some things, but it'snot quite as designed where you
see the person on the keynoteplug in the sentence in a very
curated environment, verycurated, there's still a process
you'll have to do.
Speaker 1 (17:59):
Ai will never, ever get to a point where you don't
have to prompt it, Like there'ssomething in your head Somehow.
You have to tell the computerthat.
But I'm also a product managerand I just I'm working with a
client right now and it's funnybecause I haven't done this type
of documentation in a few yearsand I was like really coming
back to me all the if-elsestatements and the if-thens and
(18:20):
all of these things.
But if you don't understand howto build out those decision
trees, user roles and thosetypes of things, how would you
prompt a computer to do that?
And I think that's somethingthat I really focus on in my
course is the really littledetails that you miss.
So even something like build mea newsfeed there's a thousand
(18:42):
variations of that Evensomething as simple as why
doesn't the image?
When I hard press the image,why doesn't it pop up and have a
native control to save todevice?
You had to have said that at acertain point.
Whether it's you're telling thecomputer in the mystical future
, where you can just build anapp by saying those things, or
you're telling your developer,there's a way that's built and
that's not going to be standardunless you flag those things.
Speaker 2 (19:05):
I don't think people put enough importance on the
non-sexy cool stuff in thebackground all of the data layer
, all of these things in thebackground, and it's not just an
application development.
I think the same thing comeswhen you start to have that
broader AI conversation, wherethey want all these super
interesting results at the endbut they don't want to put in
that legwork up front.
That says, okay, I'm going todo X, y and Z to map out our
(19:29):
environment.
I'm going to do these things tomap out decision trees and
logic and where things are andhow we want to communicate.
Speaker 1 (19:36):
And things still need to be structured in a way that
you can feed it to the AI, and Ithink that's what people miss.
Oh, ai can do anything it can,but what in your business has
been structured to collect thedata and attach it to the right
entities?
And, as we're talking, peoplelistening are probably already
opting out If else databases,structure, roles that probably
(19:57):
just seems so hard.
They're fast forwarding to thispart.
It's not hard, it's actually.
It's all common sense, and Ihave no formal tech training at
all.
I learned it all throughosmosis and learning on the job.
But if you actually just take astep back, most of it is just
logic based.
How would you ever report onsomething if you haven't asked
for it somewhere else?
And it's just little thingslike that.
(20:19):
Okay, you want to understandthe gender breakdown of your
users?
You need to ask genderbreakdown in the field there.
Okay, a topic that I talk aboutwith my clients and when I'm
talking to entrepreneurs is CRUD, and that's the basic of
everything, and I think thatknowledge goes so far.
So CRUD create, read, updateand delete and you need to think
(20:42):
about that all the time.
So even yesterday, I'm sittingin a meeting with a client and
it's a complete system I knownothing about.
It's a new client, I'm juststarting with them, and so I'm
blindly trying to lead thisscoping meeting.
But all systems are basicallythe same, right, and you're able
to ask probing questions.
So they said they wanted to adda field here.
Okay, so we're creating it here.
(21:04):
Now, where are all the placesit needs to be read?
Does it need to be read in thereports feature?
Does it need to be read in whatyou're sending to the client,
to their report?
Does it need to be updated?
Does it need to be deleted orarchived?
And even that framework is soimportant because so many times,
developers will build thingsand they don't give you the
(21:25):
ability to update them or deletethem, which is fair, because,
unless you asked for it,building that out for every
single thing would be.
You know, that's an enterpriselevel solution.
So I would say, typically,entrepreneurs, if you have a
$200,000 budget, you're going toget about 25%, right, but then
they're like what?
I should just be able to editthis?
(21:46):
Well, yeah, but that's a wholenother screen, that's a whole
nother pop-up, that's a wholenother API to actually update
the database and then update theplace that it's being shown
over here and all the differentthings.
I just think some of thosefundamental pieces.
It's logic, but once you have aframework, anyone that's not
technical can use that now andjust be like okay, I've created
it.
Where do I need to read it?
Do I need to update it?
(22:08):
What would that impact?
What screens do I need todelete it?
Speaker 2 (22:12):
So you bring up a really good point.
Even, I think, around peoplenot really understanding what
goes into everything, notunderstanding the effort
required to actually delivercertain components, and so if
they're starting to take youknow they let's say that they've
gone through that exercise.
They've asked some of thosequestions you identified at the
very beginning.
They found the right partner.
They're starting with buildingout something.
(22:32):
How do they get a sense of evenwhat that destination is?
I love to use the analogy noone ever wants to go on a road
trip if you don't know whereyou're going.
Speaker 1 (22:39):
Right.
Speaker 2 (22:41):
But how do they start to visualize the destination,
knowing that so many decisionshave to be made along the way?
It is an iterative process, butwhat advice would you have for
them at that stage of theirjourney?
Speaker 1 (22:51):
Like how do they understand what their product?
Needs to look like kind ofthing.
Speaker 2 (22:54):
Exactly.
Speaker 1 (22:55):
Yeah, I would say it really.
I do my best work inspreadsheets, so I just put a
tab for every feature to startwith and then I just map out
exactly what I think that willlook like and for every feature.
So, for example, in Team CarePal, it's a very featurerich app
.
I think we have nine keyfeatures that are all
interconnected, so it's quite abig app.
(23:15):
But when we're first buildingthat out, we have a tab for each
one of those features and then,when we're looking at newsfeed,
I went and I looked at 10different newsfeeds.
What do I need?
You need to define everything,right down to the looking
between Facebook and LinkedIn.
The way you even something isdifferent.
One has an option of fivedifferent emojis.
Linkedin has now adopted that,but Instagram you just like.
(23:38):
Do you want it to show just thenumber of people who have liked
?
Do you want it to show twonames and then others?
Do you want it?
What should those two names be?
Are those the last two thatliked it?
Are those?
Speaker 2 (23:51):
the highest follower count.
Speaker 1 (23:52):
There's all this logic that you need to keep
digging into.
Speaker 2 (23:55):
And sorry I was getting deep here.
No, but there's a level.
That's the kind of thing youneed to define.
Speaker 1 (23:58):
And so if you can start doing that, and then, once
you have your ideal, then scaleback and be like, okay, we
don't need five like options inthe beginning, do you know what?
And then it will slowly buildOnce you have your very end and
I keep hitting my mic, it'sgoing to sound weird.
It's okay, we've got a damagedeposit Once you have the whole
app built out, then you canstart breaking that down and
(24:20):
chunking it into version one,version two, version three,
because you're never going toget it all at once.
But then you can start to saywhat is like maybe I don't need
hard press to save at thebeginning, or I don't need some
of those native controls, andthen, once you have that, then
you take it to an app developerand then you can get really good
quotes because they'll becomparing apples to apples.
If you just take your 10features with a list, you're
(24:43):
going to be getting the mosthigh level quotes and none of
them are going to be accurateand you're probably, just due to
psychology, going to go withthe middle one, but it's
probably going to be wayunderscoped.
Speaker 2 (24:52):
And is that where you get into kind of change request
, purgatory and all of that kindof fun stuff or not so fun
stuff?
Speaker 1 (24:57):
Yes, because it goes back to thinking about create,
read, update, delete when you'rebuilding out that process map,
and a lot of times they'll sayokay, so this is where the
number one bit of frustrationcomes from.
I just paid $200,000 for thisapp and you're telling me you're
going to charge me $5,000 moreif I want to be able to go in
(25:20):
and edit the headings in theback end to show new ones on the
front end.
Yeah, because you never saidyou needed to update those, so
they were hard-coded and now weneed to have a mechanism to
update that, or it's those typesof things that they think
should just be obvious.
But it's not obvious becausedevelopers work on cards and I
even explain stuff like this inmy course.
(25:40):
Peek behind the curtain with me.
This is what your developer'sdoing.
He's assigned a card.
It says put in these headingsand this report, and it doesn't
say anything about edit it.
So he's just-.
He follows the instructions,does the instructions, and so if
you didn't say it, how wouldthey know?
But the more depth you add, themore man hours it takes and the
more the cost is.
Speaker 2 (26:02):
Yeah, and so I can see how, even from a if you
don't understand it how it couldbe frustrating.
Like 200 grand is a lot ofmoney, especially you're going
out, you're venturing and if youfeel like you're getting
something, it just comes down tocommunication or gaps in
expectation there.
The question that I keep comingback to is, as you, you went
through your spreadsheet,example, and all the different
things, the likes, the comments,et cetera, et cetera.
(26:23):
How on earth does someone evenknow the right questions to ask,
to be?
And maybe the answer is yourcourse.
But like there's so manyquestions and so many variables
that it sounds like are reallyimportant to consider in advance
of approaching these vendors.
How do, how does someone evenpossibly get that list to know?
Where do I have the rightquestions?
Speaker 1 (26:44):
We are living in the future.
Speaker 2 (26:46):
We have chat GPT in our pockets.
Speaker 1 (26:48):
I think there's a couple of things you can do.
Is there's some good promptsyou can do on ChatGPT?
If you're saying I want tobuild a newsfeed, give me so.
Once you've looked at all thedifferent variables and you've
tried to define as much as youcan for logic, then ask ChatGPT.
Give me 10 edge cases aroundhow users might use.
And an edge case for those whodon't know is something that
(27:10):
doesn't follow the desired userpath.
And an example of on Facebookthat might be somebody uploading
a video that's too big.
They would have kind ofparameters of how big the video
can be and the edge case wouldbe somebody tries to upload a
19-hour video and it throws anerror, or maybe the site crashes
because it doesn't even knowhow to handle it.
You want to understand edgecases and see if you want to
(27:33):
close them, like, maybe in thatcase it just does a pop-up Sorry
, your video's too big.
But you might also just want to.
There's different ways that youcould address those.
Basically, I would say go intoChatGPT, tell them a little bit
about your feature and then askit for edge cases.
Ask ChatGPT.
What are some considerations Ishould have on the UI?
What are some considerations Ishould have in different pieces
(27:55):
of this and it'll just start togive you some ideas and I've
used that pretty successfully.
Speaker 2 (28:00):
And I didn't even think about that, but the
availability of a lot of theseAI tools can be an ally on your
side as you're working throughthese different processes.
Speaker 1 (28:08):
Yeah.
Speaker 2 (28:09):
So then when you start to actually work with some
of these developers, you hearso many horror stories of the
first couple of weeks were great, it seemed like we were on the
same page.
Then all of a sudden thingsstart to go downhill really
quickly.
What are some of the commonmistakes founders or business
folks or IT folks make as theystart to work through these
projects and kind of start tobring them to fruition?
Speaker 1 (28:32):
projects and kind of start to bring them to fruition.
Yeah, they're not providingenough clarity, which I think
I'd beat to death, but it's justagain not saying what do you
think Do what you think makessense, because it'll never make
sense.
They do not know your businessand I have so many funny
examples of that.
But, yeah, it's the clarity, butit's also protecting yourself
in the contract and it is havingsomebody, I would say, on your
roster and even introducing thisat a very early stage to tell
(28:53):
the software company, whenyou're doing that contract is I
want the right to have somebodyto come in and audit this and
also understand the level ofdocumentation that they're going
to do and have some of thatwritten in the contract, because
documentation is not standardand I think more people think it
is standard but it takes a lotof time to document, time that
(29:13):
they need to charge you for.
So you want to have in yourcontract level of documentation
that will be provided andsometimes it's none because you
don't have the budget for it andyou're just moving fast and
agile.
But you also want to havethings like where the code needs
to be stored and what languageneeds to be used and what
framework needs to be used andwhat language needs to be used.
(29:33):
And what framework needs to beused Because sometimes software
development companies willrecycle old projects and you'll
end up starting a project with alot of technical debt and
you'll start seeing bugs rightaway.
Speaker 2 (29:42):
I didn't even know that was a possibility.
People would steal someone'scode from someone else or an old
project and just to get a headstart.
Is that kind of a?
Speaker 1 (29:48):
It's a pretty common practice to use libraries.
So let's say you're eitherusing a publicly available
library to build a chat featureor you've built so many chat
features that you have thisframework that you're using
constantly.
But if you have two kind ofsimilar projects, you might say,
hey, we could reuse a lot ofthat old structure and slap new
UI on it, which is actuallytotally fine as long as the code
(30:09):
base has been updated.
It's when they're trying toresell something that was built
two years ago on a lowerframework and now you're going
to be adopting a lot of thattechnical debt.
So have framework numbers inthere, have the language that
needs to be coded, have thatyou're allowed to do spot checks
.
Because the other thing isoftentimes companies won't allow
you into your AWS for a goodreason because if you mess
(30:30):
anything up, they have to payfor it, or they have to fix it
and you'll need to pay for it,and that just creates a
difficult relationship, some ofthat friction?
Speaker 2 (30:40):
I've been asked this question before and I do not
know the answer to it.
Do the languages, like I knowthey have, use cases, but how do
they matter as a technicalfounder or a IT person?
Does it matter to them whatlanguage they use?
Or how does someone even makethat choice?
Speaker 1 (30:51):
It shouldn't really matter what language is being
used, as long as it's a popularlanguage that you can find
somebody to take it over.
So they're in customdevelopment.
There's some more prominentlanguages and there's gonna be
some really obscure or olderlanguages, and they're pretty
much all fine unless your systemis like a mega system.
Some are gonna be a little bitmore efficient for certain
(31:13):
things.
I'm not the most technicalperson in the world, but there's
certain things that are justthe way you write.
That code is a little bit moreefficient and it's faster, but
it's so nominal it doesn'treally matter unless you're
Google or Facebook.
But those systems are so oldSome of them are written on
really old languages anyways.
But yeah, it doesn't reallymatter.
But you should do a quickgoogle search to understand are
other people using this language?
(31:33):
Because if you ever can't staywith that company, you need to
find someone to take it over,and I have found some clients
who have gone with companiesthat promise they can build
faster than their competitorsbecause they use their own
internal framework.
That unless you're taking avery calculated risk because
they're going to do it for socheap that you don't mind
redoing it, stay away from thatbecause you're not a very
calculated risk, because they'regoing to do it for so cheap
that you don't mind redoing it.
(31:54):
Stay away from that, becauseyou're not going to be able to
find a new developer to take itover and they might own the
rights to that platform and youmight not be able to take it
with you.
Speaker 2 (32:03):
When I was in a conversation with someone the
other day and I'm really curiouson your perspective on this
around that idea of buildcheaply, test the market and
then rebuild.
But there's so many actualpractical challenges with that
approach around.
Let's say you've onboarded acouple of users and test users.
People are giving feedback andall of a sudden they're starting
to pay you for it.
It's not quite as simple aswe're going to take it down and
(32:24):
just hold on while we spin upthe new one.
Speaker 1 (32:28):
Yeah, that is a strategy that Team CarePal tried
, and I think it's exactly whatyou're saying is, we had thought
we'll rebuild.
We went with a smaller company.
They've been great, but we justthought we might outgrow them
and we'll do a MVP and thenwe'll move on.
But, exactly like you said,you're, you have a lot of
customers on board, you have alot of data in there and the
(32:48):
customers are constantly askingfor new features.
So even though you think, okay,I'm done, my MVP was cheap, you
can't actually usually sellyour MVP.
So you're constantly makingchanges to adjust to the market
and to adapt to user feedbackand all of a sudden, this trial
system is very expensive andhard to get away from and
(33:10):
usually it's going to take yousix months to build that new
system.
So either you have to stopdevelopment on your new system
completely waiting for the newone to be built, or you're
literally throwing away moneybecause this client says I can't
use this unless you do thisthing and everything's a couple
thousand dollars.
Speaker 2 (33:25):
Yeah, everything costs money and everything costs
time.
Yeah, so that brings me into mynext question, which is really
around the sustainment ofeverything.
So you have these partners thathave been along with you for
the ride, but are most of theengagements that you're seeing
people set up for these types ofprojects do they have a finish
line?
Or when do they start totransition into maintenance mode
?
Or do they never transitioninto maintenance mode?
Speaker 1 (33:47):
Usually the end game for the software company is to
get a maintenance contractbecause that's often how they
make their money.
Those builds can have reallylow margins because things
always go wrong and so theinitial build can be lower
margin for them.
But if they can get a lot ofmaintenance clients, that's
helpful for them to have thatreoccurring revenue.
I often see that's where therelationships devolve, because
(34:11):
everything is a change order andthose hours are used up very
quickly with bugs and a lot offounders are like you built this
.
I paid you to build it and I'mpaying you to build to fix the
bugs.
And my friend Seth and he's thepresident of Corridor, a custom
software shop, he's I wouldn'thave a job if code didn't have
bugs.
I wish we could build it and itwould have no bugs forever, but
(34:31):
then you wouldn't need softwaredevelopers, really right?
You also have to remember thatyour product is living in a
living environment, and so ifit's connected to APIs, or if
your phone updates, or if thebrowser updates, all of these
things could cause bugs.
Speaker 2 (34:46):
Right, it's not just your system, it's all of these
things that are around it thatconnect into it that the
information goes back and forth.
Yeah, it's all of these thingsthat are around it, that connect
into it, that the informationgoes back and forth, and it's.
Yeah, there's no longer, andI'd be.
I'm sure there are manyexamples of this, but there's
not too many applications thatjust stand by themselves, that
don't talk to anything elseexactly like your calculator app
is one that's.
That's about it and even I don't.
The new ios update there's a.
(35:07):
It's much more advanced than itwas as well, which is very
exciting, yeah, I that.
Speaker 1 (35:11):
I can't believe they kept that calculator app the
same for as long as they did.
Speaker 2 (35:14):
Yeah, very limited upkeep on that one.
Speaker 1 (35:17):
Yeah, so I definitely see.
If the relationship moves intothis maintenance mode, that's
when there starts to be evenmore friction, because you're
like this should have been partof the initial build, I
shouldn't have to pay for this.
But you do have to remember allof that is attached to man
hours.
The other thing is the softwarecompany wants to make you happy
.
So if you're giving them, ifyou're asking them for these
(35:38):
changes that are out of scope,they might give you a few of
them.
But then when they see thespend hit this threshold, even
if it was in scope, the answerhas to be no or they have to
recoup it at some point.
So sometimes they give youthese little things along the
way and then a mistake isactually their fault and it's
hard to get them to pay for itbecause it's no matter who says
(36:00):
yeah we like.
They're a business right.
Speaker 2 (36:02):
And I've seen this as well in a lot of kind of larger
corporate service agreementswhere you know, sometimes people
as well do in the right thingsand inadvertently reinforce the
wrong behaviors and so theymight them saying yes to these
things out of the goodness oftheir heart.
They have a great relationship.
They want to do the right thingfor the customer Sometimes
leads them down these weird pathwhere either it creates this
weird expectation to what you'resaying they take a shortcut
(36:24):
because they're doing it outsideof the process, so maybe they
don't QA it properly or maybethey don't take some of the
steps.
That things would usually happenwhen it goes through this usual
rigor, but sometimes, in doingthe right things, it actually
creates these horrible outcomes.
Speaker 1 (36:38):
Yes, absolutely.
And yeah it's hard to explainthat to a cash strap founder
that you, you asked for this.
I gave it to you.
That cost me 30 extra hours ofdev time.
Now that you're saying this isthe thing you really need, it's
yeah, you've used up yourgoodwill.
And then the founders Iwouldn't have done that if.
Speaker 2 (36:58):
I knew.
Speaker 1 (36:58):
And it's.
We wouldn't have done that ifwe knew we were just trying to
be nice.
Speaker 2 (37:01):
Yeah, so I want to pivot a tiny bit towards Pivot.
Speaker 1 (37:06):
Yeah, like that, ross .
Speaker 2 (37:08):
I'm afraid to make meme references, because I feel
like I'm going to steal one ofyour memes inadvertently again
here.
Speaker 1 (37:12):
I do use the Ross one a lot, me and the founder of
CarePal.
Cindy, send it to each otherall the time, that's well used
it's in your favorites therejust to copy and paste.
Speaker 2 (37:22):
A lot of the work that we do and a lot of the
people listening are on thecorporate side of things, and so
I know you're incrediblyinvolved in the startup
community, the innovationcommunity here in Calgary, and I
have this love for the startupscene in Calgary and this
innovation community.
It's incredibly inspiring.
It's quick, moving, things arehappening, there's an energy
around it and I feel likesometimes there's such a
(37:44):
contrast to the corporate side.
I don't know if you see it thesame way, but do you do most of
your work on the startup side orare you working at all with
kind of corporate customers thatare trying to adapt some of
those more agile, startup-esqueprinciples?
Speaker 1 (37:59):
Yeah, most of my clients are startups or they're
mid-sized companies that areadopting a new product.
I usually catch people asthey're building out a new
product, but I do productmanagement as well for larger
companies, so I have dipped mytoes in that water, but I think
it is so needed and so I thinkit's the same principles that if
(38:23):
you're a mid-level manager, ifyou're an HR person, if you're
if you're anybody working in atech company, you should
understand these terms as welland you should understand the
basics of software, becauseeverything is a software company
nowadays, or you might have adev team, and I think these
principles are the sameeverywhere.
And I think I mentioned to youthat somebody on LinkedIn
(38:46):
commented and I don't thinkthey're a startup, but he was
saying oh, hearing you say frontend and back end.
That was the first time I'veheard those explained.
And then the next day somebodyasked him to hire a front-end
and back-end software developer.
So he actually knew what thatmeant.
And it just shows thedisconnect that a lot of these
people who have very high-leveljobs in these organizations
might not know those basic terms.
(39:07):
And it's what could we do andhow much more efficient could
those companies be if there wasjust more understanding.
Speaker 2 (39:13):
I could not agree more was just more understanding
.
I could not agree more.
Most of the work that I see anda lot of the innovation that I
see being driven in some ofthese larger corporate
environments isn't coming fromIT.
It's coming from theirmarketing, it's coming from
their revenue engines, it'scoming from HR and operations
and all the parts of thebusiness and sometimes and I
probably shouldn't say this, butsometimes IT is the one
actually slowing things down.
(39:50):
And so I agree with youwholeheartedly that this
language of how do you make someof these ideas come to life in
a technical capacity is alanguage that needs to be
learned, not just in IT, notjust from the technical founder,
but it needs to be like French.
It needs to become part of thecommon vernacular across
organizations, because they needto be able to communicate in
ways that can make theirorganizations digitally forward
100% and it's just like it's2025.
Speaker 1 (40:04):
We all should know these terms.
Like you said, that should becommon and they should also
understand the players on eachof the software team.
I think that would be a reallygreat step forward.
My dream would be for everybodythat works in any sort of tech
company, no matter your rolesales or HR I want you to know
what the nine or 10 common rolesare in a software company.
(40:25):
I want you to understand thesalaries ranges of these people.
I want you to understand howmuch of their time goes into
building a product, and then theprocess and some of the basics
of how software works, becausethat's where you get to build
some of this empathy andunderstand why things are taking
so long, why they're soexpensive.
It's not just lobbing thingsover the fence to your product
(40:46):
team.
It's like having that truecollaboration and empathy.
Speaker 2 (40:49):
Love it.
I feel like we probably couldtalk for another four or five
hours.
This entire conversation zoomedby and I just I want to thank
you so much for coming today.
Before we leave, there's kindof two things I want to dive
into.
One final word of advice foranyone listening outside of Take
your Course, which I feel likeis implied, but a final word of
advice for some of these folksthat are interested in learning
(41:10):
more about this.
Speaker 1 (41:12):
Be super curious.
Leverage ChatGPT and other LLMs.
You can ask so many goodquestions.
Google top 10 software terms.
Throw them into ChatGPT.
Ask it to give you a metaphor.
Ask it to bring it down to agrade two level.
There's so many ways that youcan get this information for
free and just be really curious.
(41:32):
If you hear a term, google it.
If you don't quite understandit, ask someone.
I just think the moretechnically literate we are, the
more we can all work togetherbetter.
Speaker 2 (41:40):
Amazing.
And if people want to becomeeven more technically literate
and they want to either connectwith you, learn more about you
or your course, what's the bestway to get in touch with you?
Speaker 1 (41:48):
You can follow my LinkedIn page, the Tech
Translator, or just send me amessage.
Reach out to me directly.
I'd be happy to chat.
Speaker 2 (41:54):
Awesome.
Well, thank you so much,paisley, and really appreciate
the time today.
Thank you, and this was a blast.
Thank you so much yeah.
Speaker 1 (42:00):
Thanks for having me.
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
Boysober
Have you ever wondered what life might be like if you stopped worrying about being wanted, and focused on understanding what you actually want? That was the question Hope Woodard asked herself after a string of situationships inspired her to take a break from sex and dating. She went "boysober," a personal concept that sparked a global movement among women looking to prioritize themselves over men. Now, Hope is looking to expand the ways we explore our relationship to relationships. Taking a bold, unfiltered look into modern love, romance, and self-discovery, Boysober will dive into messy stories about dating, sex, love, friendship, and breaking generational patterns—all with humor, vulnerability, and a fresh perspective.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.