
Sign up to save your podcasts
Or


This week I’m going solo to make a case that some of the most important infrastructure in your business isn’t software, it’s your people. Your systems can move data, but they can’t understand the work, so people like a customer success rep named Mark have become the intelligent integration layer between your CRM, billing platform, Slack, and email.
I walk through Mark’s customer request step by step, show where traditional APIs and automations stop, and explain how AI agents can move work with the right context when the movement isn’t deterministic. The goal isn’t to remove people from the business but to get them out of the infrastructure layer, and I close with an exercise to find where that’s happening in your own company. If you’re an investor or operator designing a workforce of people and AI agents, this one is for you.
Episode Timeline & Highlights
[0:00] – Why some of the most important infrastructure in your business is your people, not your software
[1:00] – Moving data is not the same as understanding the work, and the customer request that shows the gap
[1:31] – Mark opens the CRM, billing platform, Slack, product platform, and email to assemble the full picture
[2:56] – What Mark really did: connected systems, interpreted information, and acted as the integration layer
[5:09] – The limits of traditional integration, and a failed payment that an API can move but not understand
[6:45] – Where deterministic movement is perfect: if X happens, do Y
[7:50] – Systems could never answer who should receive the work, so people provided the intelligence
[8:28] – How an AI agent handles the failed payment using customer context, policies, and its authority
[10:21] – Moving the work with the relevant context, not a task that just says please handle
[12:20] – Not every movement needs an agent: if X reliably means Y, use the API, automation, or rule
[13:19] – Scale: a person monitors 50 situations while an agent can stay aware across thousands
[14:52] – The goal is to get people out of the infrastructure layer, not out of the business
[16:32] – A person who is the right worker for the job versus a person required to connect the work
[17:36] – Receive, execute, hand off, and who provides the intelligence between those stages
[19:59] – The exercise: find the people who seem to know how everything connects and watch what they do
[21:29] – If the movement needs intelligence, could an AI agent provide it instead of a person?
Key Takeaways
Links & Resources
If this made you think of the Mark in your own business, spend a week watching what he actually does between your systems. You may find work that was never his job to begin with. More high-signal conversations coming next.
This week I’m going solo to talk about the pattern underneath almost everything your business does: receive, execute, hand off. Handing work to the next person or AI agent isn’t enough, because they also need the context to continue it, and I show why with an AI customer success agent named Maya and a customer success leader named Sarah.
We get into why access to your CRM, Slack, and email is not the same as context, how Sarah’s call with an at risk customer creates new context that has to travel back to Maya, and why a handoff and true continuity are two different standards. I also connect it to infrastructure architecture, the third pillar of the AI labor architecture framework, and close with an exercise you can run on one handoff this week. If you’re an operator or investor designing a workforce of people and AI agents, this one is for you.
Episode Timeline & Highlights
[0:00] – Almost all work follows one cycle: receive, execute, hand off
[1:31] – Meet Maya, an AI customer success agent who spots a customer at serious risk of leaving
[2:35] – Maya hands the at risk customer to Sarah, a customer success leader, with no background
[3:35] – Sarah has to rebuild the story from the CRM, support system, billing, email, and Slack
[4:54] – Why context is not more information, a bigger context window, or access to everything
[6:20] – Access to the CRM is not the same as context, only the raw materials to build it
[7:32] – The better question: what does this worker need to understand to execute this responsibility?
[8:06] – Sarah calls the customer and creates new context: a business change and a promise by Friday
[9:31] – When the work returns to Maya, a CRM status change is not the same as context
[11:45] – This isn’t an AI problem, it’s a work problem: meaning gets left behind every time work moves
[12:13] – Why so much context lives between your systems or inside your people’s heads
[14:14] – Good infrastructure gives each worker the right context for their bounded responsibility
[16:37] – Infrastructure architecture as the third pillar of the AI labor architecture framework
[18:37] – The difference between a handoff and continuity
[19:39] – The exercise: pick one handoff and stand in the shoes of the worker receiving it
[21:30] – People inside your business have become part of the infrastructure, compensating for the friction
5 Key Takeaways
Links & Resources
If this made you think about how work changes hands in your own business, pick one handoff this week and stand in the shoes of the person receiving it. You’ll probably find someone quietly carrying context around in their head. More high-signal conversations coming next.
This week I'm going solo to ask a question most business owners skip. You probably run a CRM, a billing platform, a support desk, and 10 or 20 other systems, so how does work actually move between them? I break down why those systems are great at storing information but terrible at moving the next piece of work, and why that gap gets exposed the moment you add AI agents to your workforce.
I walk through a real world example with an AI customer success agent named Maya, who does her job perfectly and then hits a wall when the work needs to go to a person. From there we get into shared execution, why people like Sarah have been the invisible connective tissue in your operations for decades, and a simple exercise to find where work stalls in your own business. If you're an investor or operator thinking about AI agents, workflow automation, and business infrastructure, this one is for you.
Episode Timeline & Highlights
[0:00] – Why most businesses run 10 to 20 systems that store information but don't move work
[1:06] – The real question: how does work move through your business after a status changes?
[1:40] – Why the answer is usually manual: emails, Slack posts, and copying data between systems
[2:57] – Why people have always been the ones moving work between your CRM, billing, and support tools
[4:38] – Why AI agents expose an infrastructure gap that businesses were never built to handle
[5:13] – Meet Maya, an AI customer success agent who spots a customer at risk of leaving
[6:52] – What happens when Maya hands off the work: a task, an email, a Slack message, or a ticket?
[8:23] – The constraint moves: AI agents become faster than the infrastructure around them
[10:36] – Why moving data between systems is not the same as moving work
[12:20] – Why shared execution between people, AI agents, and systems only works if work can move
[13:28] – Islands of execution, and how Sarah's invisible work fills gaps in your architecture
[16:10] – The infrastructure questions to ask: what triggers movement and who owns the work next
[17:06] – The exercise: pick one piece of work and follow it across your organization
[18:12] – The test: if the people moving this work disappeared tomorrow, would your systems know what to do?
[19:37] – Why context has to move with the work, not just a notification
Key Takeaways
Links & Resources
If this made you stop and wonder where work sits waiting in your own business, pick one process this week and follow it from start to finish. You'll probably find your own version of Sarah. More high-signal conversations coming next.
This week, Jordan goes solo again to talk about a category of work that never shows up on an org chart: the checking, chasing, reminding, and reconciling that keeps a business running even though nobody assigned it to anyone. He walks through a hypothetical operations manager named Sarah, the kind of person every business has, who ends up compensating for a dozen invisible gaps a day without anyone realizing it's even happening.
Jordan argues this "invisible work" might be one of the biggest blind spots when it comes to finding real opportunities for AI, because if you only look at job descriptions and process maps, you'll never see it. The real question isn't whether an AI agent could do Sarah's job. It's why that work exists in the first place, and once you can see it, you can finally decide what should happen to it.
Episode Timeline & Highlights
[0:00] – Opens by describing a category of work that doesn't appear on any org chart, job description, or process map
[0:26] – Describes this as "the work between the work": checking, chasing, remembering, reminding, coordinating, and moving information around
[1:07] – Points out most businesses only think about work in terms of formally defined departments like sales, customer success, finance, and operations
[1:39] – Introduces a hypothetical operations manager, Sarah, described as indispensable because she knows how everything actually works
[2:11] – Walks through Sarah's day: she notices an incomplete customer step nobody asked her to check
[2:35] – Sarah catches a data mismatch between two systems and has to figure out which one is correct
[3:04] – Sarah recalls a customer's unusual arrangement from memory because the information isn't reliably documented anywhere
[3:28] – Sarah tracks down a stalled task, discovers two people assumed the other was handling it, and gets it moving again
[4:22] – Imagines Sarah disappearing for two weeks and the cascade of missed follow-ups and dropped context that follows
[5:28] – Argues Sarah isn't just doing her job, she's compensating for gaps in how the business is architected
[6:22] – Names this pattern "invisible work" and explains why it has to be recognized as work before it can be redesigned
[8:20] – Points out Sarah's actual job description almost certainly doesn't mention remembering missing information, chasing failed processes, or reconciling systems
[9:16] – Warns against just automating the compensation instead of fixing the underlying structural problem
[10:13] – Distinguishes between invisible work that is legitimate and should be formally assigned, and invisible work that only exists because something else in the business is broken
[13:08] – Offers a simple exercise: find the person everyone goes to when something gets stuck, and write down everything they actually do instead of their job description
[14:47] – Closes with the idea that some invisible work will go to people, some to AI agents, some will be shared, and some should disappear entirely once it's actually visible
5 Key Takeaways
Links & Resources
If you've got a Sarah in your business, this is the week to actually write down everything she does instead of just being grateful she does it. More high-signal conversations coming next.
This week, that real estate tech guy himself, Jordan Samuel Fleming, goes solo to tackle one of the biggest questions AI raises for business owners: not what can a person or an AI agent do, but who should do it. Using a hypothetical AI sales agent named Daniel, he breaks down why the old dividing lines between "human work" and "AI work" are starting to fall apart.
Jordan introduces the idea of shared execution, where a single responsibility gets carried by a mix of people and AI agents at different moments, based on what actually produces the best outcome rather than who has always done the work. It's a practical reframe for any business owner trying to figure out where AI actually belongs in their operation.
[0:00] – Opens with the real question replacing "who can do the work": who should do it
[0:36] – Explains why, for most of history, work requiring judgment always landed on a person by default
[1:15] – AI agents can now communicate, make decisions, exercise judgment, and manage relationships on their own
[1:53] – Warns against drawing a simple dividing line between "human work" and "AI work"
[3:05] – Argues the future workforce gets designed responsibility by responsibility, not by two separate lists
[3:35] – Introduces a hypothetical AI sales agent, Daniel, fully trained on product, pricing, and qualification criteria
[4:38] – A new lead arrives and Daniel handles the entire qualifying conversation with no need for a human
[5:10] – Daniel flags something unusual: this deal could be worth half a million dollars
[5:46] – The real question becomes not "can Daniel continue" but who creates the most value in this specific moment
[7:26] – Flips the example: what happens if a company insists every one of 2,000 leads gets a personal follow up from a salesperson
[8:02] – Points out Daniel may actually maintain relationships better than a person, with no forgotten follow ups
[10:30] – Value belongs to whoever is actually contributing to the outcome, not to a category of worker
[11:05] – Introduces "shared execution," where multiple types of labor intentionally share one outcome
[13:15] – Distinguishes capability from suitability: being able to do something doesn't mean you're the one who should
[14:56] – The labor split isn't fixed. An AI agent might start by owning 20% of a responsibility and grow from there
[18:22] – Closes with the challenge: stop asking "could I do this" and start asking "who should do this, and why"
If there's one responsibility in your business you've been assuming needs a person just because that's who's always done it, this is the week to go take a second look. More high-signal conversations coming next.
This week I want to introduce the second part of the framework I've been building across these videos: bounded responsibility. Think about the best person you've ever managed, someone you trusted with real autonomy. That trust almost certainly came from clear boundaries, not the absence of them. They knew what they owned, what information they had access to, what decisions they could make, and exactly when to bring someone else in.
I walk through a detailed example: a customer success rep named Mark, given the vague instruction to "keep customers happy, use your judgment." That sounds empowering, but it actually forces Mark to constantly guess, ask permission, and learn the real boundaries through trial and error over time. Compare that to clearly defining his responsibility up front, the outcome he owns, the information he can access, what he's authorized to decide, and where he must escalate, and you'll find his autonomy actually increases. This is exactly the same conversation we need to have when handing responsibility to an AI agent, and I break bounded responsibility down into four elements: role, context, skills, and escalation.
Episode Timeline & Highlights
[0:00] – Thinking about the best person you've ever managed, and why you trusted them
[0:28] – What actually makes someone trustworthy: clear boundaries, not the absence of rules
[1:02] – Why AI management isn't an entirely new set of principles from human management
[1:36] – Introducing bounded responsibility: being clear on what a worker is allowed to do, not just what they should do
[2:16] – Why the word "bounded" matters, and how clear boundaries actually create autonomy
[2:47] – Introducing Mark, a customer success rep given a vague, seemingly empowering instruction
[3:11] – The problem: Mark has to constantly guess and ask permission on nearly every decision
[4:32] – How Mark eventually learns the boundaries anyway, just slowly and informally
[4:59] – Why that's actually a failure of design, not a success story about Mark
[5:32] – Rewriting Mark's responsibility with real clarity: outcome, access, authority, and stopping points
[6:34] – Why this actually increases Mark's autonomy instead of restricting it
[7:08] – Introducing an AI customer success agent, Alex, capable of far more than he should be authorized to do
[7:37] – Why "what can Alex do" is the wrong question, and "what should Alex be authorized to do" is the right one
[9:09] – Confirming this is a labor architecture principle, not something unique to AI
[9:50] – Applying bounded responsibility to a previously pulled-apart job: lead qualification
[11:36] – A real edge case: what happens when a normally disqualified lead turns out to be worth half a million dollars
[11:36] – Introducing the four elements of bounded responsibility: role, context, skills, and escalation
[12:39] – Why access to everything isn't the goal, only the information needed for that specific responsibility
[13:07] – Escalation as possibly the most important element: knowing exactly where a worker must stop
[14:23] – How organizations quietly rely on tenure and unwritten rules to paper over undefined responsibility
[15:40] – Why AI isn't creating the need for boundaries, it's exposing responsibility that was always poorly defined
[17:25] – The exercise: does your best person perform well because of design, or because of tenure
[19:03] – The four questions to ask about any responsibility: outcome, access, authority, and stopping point
[20:01] – Why the future of work is designing the work itself, not separate systems for people and AI
5 Key Takeaways
Links & Resources
Thanks for tuning in to this one. If this got you rethinking how clearly a responsibility is actually defined in your own business, pick one of your best people this week and ask the four questions: what outcome, what access, what authority, what escalation point. Head over to thatrealestatetechguy.com for all the episodes and some great discounts on the tech we talk about. More high-signal conversations coming next.
This week I want to challenge one of the biggest promises being made about AI right now: automation. It sounds great, take an existing process and make it faster with AI, but I think there's a question that gets skipped way too often. Should this process exist in the first place? When you automate a process without asking that, you're quietly assuming every step, every handoff, and every approval is actually necessary.
I walk through a detailed example: a sales discount approval process, where a salesperson has to escalate a discount request to a manager because the manager holds the judgment and authority to decide. You can automate every step of that request and response cycle and make it much faster, or you can ask why the approval exists at all, and realize that once an AI agent understands your commercial boundaries, most of that back-and-forth can disappear entirely. This is the same mistake many businesses made during digital transformation: they digitized their paper processes instead of asking whether those processes should still exist. Pick one process in your own business this week, and instead of asking what you can automate, ask why each step exists in the first place.
Episode Timeline & Highlights
[0:00] – The big promise of AI automation, and the question that gets skipped
[0:31] – Why automating an existing process assumes the process itself is correct
[1:44] – Introducing the example: a sales discount that requires manager approval
[2:07] – Walking through the current process: request, context gathering, decision, and response
[3:06] – What an automation vendor would immediately offer to speed up that process
[4:06] – The better question: why does the approval process exist in the first place
[4:34] – The real reason: judgment and commercial boundaries live inside the manager's head
[5:07] – Introducing AI labor trained on commercial policy, pricing, and customer history
[5:40] – Setting clear boundaries: what an AI agent can decide, and what still escalates
[6:14] – What happens to the approval process once those boundaries exist
[7:29] – Comparing automating a process versus redesigning the work itself
[8:01] – The digital transformation parallel: paper forms became digital forms, not new processes
[9:33] – Why AI is a new source of intelligent labor, not just a faster way to move information
[10:03] – The bigger question: how many of your processes exist just to move information between people
[11:26] – Why your existing processes aren't sacred, just how work got done given past constraints
[11:56] – Some processes should be kept, some automated, some redesigned, and some eliminated entirely
[12:25] – Separating the actual work (a commercial decision) from the process steps built around it
[13:01] – Why starting with the work avoids the traps hidden in technology, job titles, and process
[13:57] – The uncomfortable discovery: some of what you're about to automate probably shouldn't exist
[14:55] – Framing AI as a labor question rather than a technology question
[16:00] – The exercise: pick one process, map its steps, and ask why each one exists
[17:01] – Why the biggest AI opportunity might be realizing you don't need the process at all
5 Key Takeaways
Links & Resources
Thanks for tuning in to this one. If this got you second-guessing a process you were about to automate, that's exactly the point, pick one this week and ask why each step actually exists before you make it faster. Head over to thatrealestatetechguy.com for all the episodes and some great discounts on the tech we talk about. More high-signal conversations coming next.
This week I want to go deeper into an idea I touched on before: your job descriptions might actually be hiding how your business really works. I use a detailed example, a salesperson named Jennifer, and follow her through an entire day to show that "salesperson" isn't really one job. It's a bundle of completely different kinds of work, administrative tasks, predictable execution, pattern recognition, and high-value human judgment, that all got stitched together simply because one person had to do all of it.
Once you stop asking "how much of Jennifer's job can AI do" and instead pull the bundle apart into its individual responsibilities, initial contact, qualification, scheduling, nurture, negotiation, closing, you can make a much smarter decision about how each piece should actually be executed. This is part of what I call work architecture, the first section of my AI Labor Architecture framework in my new book, The AI Workforce. Try this yourself: pick one important person on your team, forget their title for 30 minutes, and just follow the actual work that crosses their desk.
Episode Timeline & Highlights
[0:00] – Where would you even start explaining how your business works?
[0:35] – Why a job description shows how work got bundled, not what the work actually is
[1:04] – Introducing Jennifer, a top salesperson, and her simple-sounding job title
[1:32] – Following Jennifer through a full day: a lead comes in and she makes contact
[1:58] – The research and qualification work: comparing a lead against past successful customers
[2:25] – The scheduling grind: calendar links, availability, and the back and forth to book a meeting
[2:57] – Preparing for and running the meeting, then handling objections when they don't buy right away
[3:20] – The nurture and follow-up work that keeps an opportunity from disappearing
[3:32] – Pricing, approvals, and contract negotiation on the way to finally closing the deal
[4:04] – Breaking down the four different types of work bundled into "salesperson"
[5:12] – Why intelligent work has always required a person, and how that shaped the modern job
[5:41] – Jennifer's job title as simply the container used to organize the work, not the work itself
[6:16] – Why "how much of Jennifer's job can AI do" is the wrong question to start with
[6:49] – Pulling the job apart into its individual responsibilities: qualification, research, scheduling, and more
[7:30] – What it looks like once each responsibility can be assigned independently
[8:04] – The real shift: not replacing Jennifer, but no longer treating Jennifer as the architecture
[8:40] – Why most businesses will preserve the same work bundles even after adding AI
[9:46] – Why the assumption behind those bundles has now changed
[10:17] – The exercise: pick someone important and follow their actual work, not their job description
[10:52] – Why the real job usually isn't captured in the written job description at all
[11:25] – What makes your best people better: the judgment and context nobody ever documented
[12:01] – The risk of only automating obvious tasks and calling it a redesign
[12:43] – Realizing a "job" might actually be six or twelve separate responsibilities
[13:50] – Separating the work, the responsibility, and the execution once again
[14:23] – Revisiting Jennifer: an incredible closer spending half her week on work that doesn't need her
[15:20] – Where this shows up everywhere: managers as human routing systems, founders making decisions they should have handed off years ago
[15:41] – Introducing work architecture as part of the AI Labor Architecture framework
[16:27] – The 30 minute exercise: forget the title, follow the actual work
[17:37] – Where to find The AI Workforce and get notified when it's available
5 Key Takeaways
Links & Resources
Thanks for tuning in to this one. If this got you thinking about someone on your own team, try the exercise this week: forget their title for 30 minutes and just follow the work. Head over to thatrealestatetechguy.com for all the episodes and some great discounts on the tech we talk about. More high-signal conversations coming next.
This week I want to tackle a question I hear constantly from business owners, and I think it's actually the wrong question to be asking: "what can AI do in my business?" It feels reasonable given how fast AI capability is moving, but starting there makes AI the center of the conversation when it should be the work. Your business exists because of outcomes that need to be produced, not because of a tool that needs a job to do.
This is the first part of what I call the AI Labor Architecture framework in my new book, The AI Workforce, and it's the starting point for every other decision that follows. If you try nothing else this week, pick one part of your business and ask what actually needs to happen there, not what an AI agent could do, and not even who's currently doing it.
Episode Timeline & Highlights
[0:00] – The common question business owners keep asking, and why it's the wrong one
[0:57] – Why AI isn't the center of your business, the work is
[1:28] – Reversing the question: from "what can AI do" to "what work actually needs to be done"
[2:00] – Introducing the SaaS onboarding example
[2:33] – What a CEO sees when a capable new AI agent looks able to handle onboarding
[3:39] – Why "could she do onboarding" is still the wrong question, even if the answer is yes
[4:12] – Breaking onboarding down piece by piece: information gathering, account setup, and interpretation
[4:41] – What actually happens after setup: helping the customer understand what's been done
[5:10] – The follow-up work: noticing when a customer gets stuck or disappears
[5:49] – Why "onboarding" was always a bundle of very different kinds of work sitting inside one role
[6:34] – A break to highlight smrtPhone, the show's sponsor, and its 5,000 free calling minutes offer
[7:07] – Introducing AI labor as a way to unbundle execution from any one person
[7:37] – What this actually looks like: an AI agent gathering information and following up consistently
[8:06] – When a person still needs to be brought in, and why they'd have full context already assembled
[8:47] – Why capability doesn't tell you how your business should be designed
[9:18] – The real questions to start with: where judgment, consistency, context, and relationship matter most
[9:57] – Why so much of the current AI conversation gets the order backwards
[10:24] – The hiring analogy: choosing a job for someone because of their resume, not their fit
[11:31] – Why businesses have always been built around people, and why that shaped how we see "the business" itself
[12:07] – Separating three things that used to travel together: the work, the responsibility, and the execution
[13:14] – Why the order matters: starting with the work, not the AI agent
[13:56] – Introducing work architecture as the first part of the AI Labor Architecture framework
[14:29] – Why capability comes later, after you understand your business and its outcomes
[15:04] – Where to sign up to be notified when the book, The AI Workforce, launches
[15:32] – The one exercise to try this week: pick one part of your business and start with the work
5 Key Takeaways
Links & Resources
Thanks for tuning in to this one. If this got you rethinking how you look at a role in your own business, try the exercise: pick one part of it this week and ask what actually needs to happen, not what an AI agent could do. Head over to thatrealestatetechguy.com for all the episodes and some great discounts on the tech we talk about. More high-signal conversations coming next.
This week I want to dig into one idea that I think is going to cause a lot of businesses real problems if they don't get ahead of it: the assumption that dropping an AI agent into a part of your business automatically creates leverage. It sounds obvious on the surface, an AI that can work faster and handle more volume than a person should scale your output. But I don't think that's actually how leverage works with AI, and I want to walk through exactly why.
I use a simple sales team example to show what happens when you introduce an AI agent that can produce ten times the qualified opportunities your team used to generate. Instead of ten times the leverage, you often get ten times the problem, because every other part of your business was built around human capacity constraints that AI doesn't share. The real fix isn't just adding AI where you can, it's asking what happens to everything around it once you do, and in most cases, redesigning the whole system rather than just automating the old one. This is the exact question that led me to write my new book, The AI Workforce, and the framework inside it, the AI Labor Architecture, which I'll be building on in the episodes ahead.
Episode Timeline & Highlights:
[0:00] – The core assumption about AI that's going to cause businesses real problems
[0:27] – Why adding an AI agent doesn't automatically create leverage
[0:58] – The sales team example: introducing an AI agent that can engage thousands of leads
[1:33] – What happens when a team built for 50 qualified opportunities a week suddenly gets 500
[2:37] – Why ten times the output can become ten times the problem instead of ten times the leverage
[3:15] – Why businesses have been designed around human labor constraints for hundreds of years
[4:33] – A break to highlight smrtPhone, the show's sponsor, and its 5,000 free calling minutes offer
[5:02] – Digital employees don't share the same constraints as human labor
[5:46] – Why moving a bottleneck isn't the same as removing it
[6:18] – The better question: not "where can we add AI" but "what happens to everything around it"
[6:55] – Redesigning the sales process itself around what an AI agent can actually do
[7:35] – Why this is redesigning the process, not just automating the old one
[8:03] – How human capacity assumptions are baked into almost every process in a business
[8:38] – The real questions leaders need to ask: what stays human, what becomes AI, what changes
[9:16] – Why this question led Jordan to write his new book, The AI Workforce
[9:49] – Introducing the AI Labor Architecture framework at the center of the book
[11:00] – Why the winning companies will be the ones that redesign around AI, not just adopt the most tools
[11:26] – Where to sign up to be notified when the book launches
5 Key Takeaways
Thanks for tuning in to this one. If this got you thinking differently about where you're adding AI in your own business, that's exactly the point, the redesign question matters more than the tool question. Head over to thatrealestatetechguy.com for all the episodes and some great discounts on the tech we talk about. More high-signal conversations coming next.
From the publisher's feed
Welcome to the only weekly podcast dedicated to the Real Estate Investing Tech Stack, hosted by Jordan Samuel Fleming. Jordan has been heavily involved in building technology tools for Real Estate…