In this episode, get a look behind the curtain at how one of the most widely used workflow platforms is thinking about AI at this point in time. From building personal and shared context for your tools, to where AI collaboration is most advanced, to a not-so-far-off future of not having to configure automation.

A workbench metaphor

In woodworking, a workbench is often one of a craftsman’s first projects because it’s the thing that makes every other project possible. He sees a similar pattern happening among some of the power users of AI. They’re building a personalized infrastructure of tools that works for them.

His own version of this lives in Cursor, a workspace he calls “Brain” that connects to his calendar, his documents, and his tools. When he opens it in the morning, it already knows what he’s working on for the day.

“It creates my daily brief. Who am I going to meet with today? Does a bit of research on them, prep work, connect it to all the tools I use.”

That’s the noteworthy difference between using AI reactively (opening a tab, pasting some context, and getting an output) vs. using it as infrastructure. The workbench doesn’t wait to be asked, it’s already running.

The lack of shared context remains mostly unresolved

Building a personal workbench is a fantastic start. But getting a whole team working the same way is a tougher nut to crack, and one Chris thinks the industry hasn’t (quite yet).

“We’re transforming how individuals work. We’re not yet at the point where we’re transforming how teams work together.”

Part of what makes this difficult is structural. AI collaboration is likely most advanced in coding, and that makes sense when you think about it. Software development already has a human-to-human collaboration model that translates naturally to human-to-AI. The context lives in the code, it’s version-controlled, and it’s shared. Everyone’s working from the same source of truth.

Most other knowledge work isn’t built that way. Context lives in Slack threads, in email chains, in someone’s head. Every time you sit down with AI to do something meaningful, you’re rebuilding that context from scratch.

Zapier’s current approach is to change the underlying structure of how context is stored and shared, so that whatever tool anyone on the team reaches for, the shared knowledge is already there waiting. They have a shared Google Drive folder of Markdown files synced to everyone’s machine. Simple, portable, and tool-agnostic. Whether someone is working in Cursor, Claude Code, or something else entirely, they’re all pulling from the same well.

Having an open posture for disruption

Chris has been at Zapier for nearly a decade, and one of the things he’s most proud of is how the company responds to disruption:

“Every moment where there’s been something disruptive, whether that’s coming from customers, coming from the market, we don’t think, how do we make the existing thing survive? We think somebody’s going to disrupt us. Let it be us.”

So when ChatGPT dropped, the response was consistent with that. Their CEO called a code red to stop normal operations, set aside the roadmap, and rethink the fundamentals. It opened up a period of exploration, with parallel experiments running, some competing with each other. Chris says that a lot of what Zapier has shipped recently traces back to that time.

Now the work looks a little different! Chris describes the current phase as consolidation - taking everything that was learned and pulling it into something more coherent. The risk of moving fast and experimenting broadly is that users end up having to make one-way-door choices between products solving similar problems in slightly different ways. Closing that gap is where the focus is now with their team.

The continued blurring of roles

The idea of T-shaped skills have been around for some time: deep expertise in one area with broad capability across others. What’s changing is the width of that horizontal bar.

Becoming deeply expert at something still takes time. But becoming capable enough to contribute meaningfully across product, design, and engineering is more accessible. Some of Zapier’s designers are reaching for Claude Code instead of Figma when they need to prototype. Not because they’ve become engineers, but because the distance between having an idea and having a working version of it has collapsed. The strict boundaries that used to define who did what are getting a little harder to justify.

Even still, Chris and George are both quick to acknowledge the distinction: capable isn’t the same as expert. The polish a seasoned designer brings in Figma or the architectural decisions an experienced engineer makes under the hood is critical judgement that takes years to develop. What’s shifted is the on-ramp.

“It is way easier to become more capable. But becoming an expert still takes 10,000 hours.”

Chris connects all of this to a bigger question for the industry. Referencing the “N of one software” - the idea that when building is cheap enough, anyone can create something hyper-personalized for themselves or their specific team rather than buying off the shelf. That has potentially scary implications for the SaaS market broadly. And for product managers specifically, it changes the nature of the work. Overall, Chris thinks that the blurring of the lines between user, builder, and product manager are mostly a good thing.

What’s the next great frontier at Zapier?

Zapier’s brand reputation was built on making automation accessible to people who couldn’t code. The next version of that is more ambitious: what if you never had to think about automation at all?

Right now, even with an AI-assisted setup, there’s still cognitive load on the user. The editor is visible, the field mapping is your problem, and when something breaks, you’re the one who has to fix it. At Zapier they are exploring what it looks like when the system understands what you’re trying to accomplish and handles the rest. Sans the configuration and troubleshooting.

And it’s not as far off as it sounds! The gap between hitting an error and resolving it is already closing. When it closes entirely, there can be a whole new class of users who will use automation without ever knowing that’s what they’re doing. For a platform that has spent a decade watching how people actually get work done, it’s one of their most exciting chapters to date. At Crema, our staff can’t wait to see it unfold.

People of Product is brought to you by Crema - a design & technology consultancy

A product org with an unusual edge

If you haven’t heard of Enverus, it is the world’s largest SaaS-based data, software, and analytics company dedicated to the energy industry. What makes Enverus unusual is that the organization has a large team of intelligence analysts producing investor-grade market research. The products they build are the engine that generates the research outcomes. That tight loop between data, analysis, and software creates a competitive advantage that most product organizations simply don’t have access to. Which is part of what makes Jimmy’s perspective so interesting.

Find the market problem and everything else follows

After nearly 30 years in product across restaurants, retail automation, fleet transportation, home automation, and now energy, Jimmy keeps coming back to one core truth: if you get nothing else right, find market problems.

He uses the Pragmatic framework’s language: pervasive, compelling, urgent, with a willingness to pay. But the insight is less about concrete methodology and more about disposition.

“You do that through lots of intimate customer contact. You don’t do that in the office. You don’t do that by reading the trade rags.”

And when you’re in those customer conversations, Jimmy echoes Melissa Perry (Escaping The Build Trap): fall in love with the problem, not your product. The courage required for good product work includes being willing to hear that the customer’s most urgent problems have nothing to do with what you’re currently building.

Red, yellow, green: how to think about your product team’s time

Jimmy uses a simple framework to evaluate where product managers are spending their energy:

Red is customer support mode: someone has a problem, stop everything and fix it. If you’re here too often, something systemic is broken. Don’t just route around it, go and solve the root cause.

Yellow is involvement in active transactions: sales cycles, renewals, deals. Not bad, but not the highest use of a PM’s time. Too much yellow can be a signal that product-market fit isn’t where it should be.

Green is the good stuff: conversations with no transaction attached, no agenda, just understanding the customer’s world and what they’re worried about next.

“If you’re spending too much time in red and yellow and not enough time in green, that’s not a good future indicator.”

Culture can’t be processed into existence

Cross-functional alignment is a culture problem first and a process problem second. You cannot process your way out of a culture that has “us-versus-them” baked into it.

At Enverus, the standard is simple and non-negotiable: if another function is struggling, it’s your problem too. There’s no daylight between executive leadership and no finger-pointing across department lines. Roadmap sessions include representation from most functions in the company so that nobody is surprised. And more importantly, nobody misses the chance to contribute.

“Without [the culture], you could have all the roadmap meetings you want. It wouldn’t matter.”

AI is a foundational technology comparable to fire

There’s this category of technology called a general-purpose technology, like electricity or heat engines. They are powerful, broadly applicable, and transformational across all industries. Jimmy argues that AI clears that bar easily, and he goes further. There’s an even more fundamental category: technologies that expand what humans can do at all, like the discovery of fire.

“Artificial intelligence is a foundational technology. It’s like stone tools or fire. It’s that big of a deal.”

If AI is truly foundational, then the question “could AI change how I do this?” stops being something you ask occasionally. It becomes the default first question for near anything. And if you can’t think of an answer right now, then you keep asking.

What makes this especially hard for business leaders is the pace. Jimmy describes what his professor called the “dual prediction process” — you’re always trying to predict both where customer needs are headed and whether your organization can get there. That’s always been difficult. Now you’re trying to do it while a foundational technology is advancing with step changes in capability that appear seemingly at random.

The gap between Thanksgiving and New Year’s in AI coding capability this past year (2025), Jimmy says, was enough to make even the most skeptical, hard-edged technologists stop and say whoa!

When engineering is no longer the bottleneck

Jimmy is watching where the constraint is shifting in software development and thinks Nate Jones had it right: as AI accelerates the velocity of building, the bottleneck moves toward go-to-market. Sales, marketing, and ultimately customers themselves have a natural absorption rate, meaning there’s a ceiling on how much change they can take in at once.

That creates an imperative for product teams. Product teams need to recognize that customers are about to be inundated with new things from every direction. The bar for what earns their attention is going up.

“You better be making the thing that rises to the top.”

Which brings it back, as it always does, to market problems. The highest-quality problem you can find, for a customer who is urgently and compellingly motivated to solve it.

People of Product is brought to you by Crema - a design & technology consultancy

On this podcast episode, I sat down with Ross Brown and Deric Mendez, two senior software engineers at my company, Crema, to talk about their experience with “vibe coding” which is the catchall term for using AI to generate, debug, and build software.

The mental image of a codebase that looks like a messy apartment after an endless party captures something essential about where we are with AI coding tools right now. We know the promise. The productivity gains are tangible. But the gap between what these tools can do and what we think they can do is wider than most people realize. Let’s dive into it - with the pros!

There’s a scary productivity / learning tradeoff

Anyone who’s played with these tools long has likely seen the tradeoff:

“When you have it [AI] construct something for you, you’re offloading your labor, but you’re also offloading your learning—or really sacrificing that for productivity.”

This isn’t just a philosophical concern, it’s pretty practical. When Deric inherited my 125-hour vibe coding project, he started over from scratch. Not only because the code was unusable (though it kind of was), but because understanding what the AI had built would have taken longer than just building it himself and he wouldn’t have learned anything in the process.

Think about that for a second. The efficiency gain disappeared the moment the code needed to be maintained, extended, or understood by someone who didn’t watch it being generated line by line. If we’re not careful, we’ll optimize ourselves out of understanding the things we build.

What works

• Documentation generation: Deric pointed his AI at a messy codebase and asked, “What is this project doing?” It gave him a clean breakdown and even formatted it into user stories. “I don’t have to go find and sift through all the files to see what it really needed,” he said. This is a legitimate time-saver.

• Debugging partner: Ross described it as a “debug buddy”—helpful for expediting paths you’d probably go down anyway. Not replacing expertise, but accelerating it. “It’s helpful because it expedites some paths that I probably would go down eventually, but saves a lot of time,” he said. Critically: “I still feel like I’m learning when doing those exercises.”

• Pattern recognition: Deric used AI to document architectural patterns already in their codebase, creating architectural decision records (ADRs) that help guide future development. This is smart—using AI to codify tribal knowledge.

⭐ Here’s what these successes have in common: they all require someone who knows what they’re looking at.

Thinking notes and being held accountable

Ross mentioned something I hadn’t noticed:

“Sometimes I wish there was like a speed control because I really do enjoy at least in Claude Opus when you type something, it spits back at you a summary of what it thinks you meant.”

He’s talking about Claude’s “thinking notes”—the AI’s reasoning process that flashes briefly before collapsing into a simple “I was thinking for 10 seconds.”

“Sometimes I just wish that was all there,” Ross said. “Especially if I’m doing something that I’m going to put into production code and I’m using this as a tool to do it, I want to make sure that its assumptions align with my assumptions.

Keeping “experts in the loop”

Unsurprisingly AI coding tools are exponentially more valuable to people who already know how to code. Expert devs can spot when it’s using an outdated library version. They know when to take control and write the code themselves. They understand the implications of architectural decisions the AI makes.

The promise sold to people like me—non-technical founders and product managers who can now build production-ready software—hasn’t materialized. Not really. I can build impressive prototypes in an afternoon. But “impressive prototype” and “production-ready software that won’t get hacked or break when users actually touch it” are different universes.

As I told Ross and Deric, I haven’t seen any of that actually hit a marketplace successfully and not been hacked. They both nodded knowingly. Of course not.

Where we go from here

The conversation isn’t over. Things are changing fast, and we’re all still figuring out what role these tools should play in our work, our learning, and our craft.

I asked Ross and Deric if we could do this again in three to six months. Something tells me our answers will be drastically different then, same as they were six months ago.

Ross went from “I don’t know about this stuff” to finding genuine value in targeted use cases. Deric went from curious to building spec-driven workflows that make AI truly useful. And me? I learned that being able to prompt an AI doesn’t make me a developer any more than being able to use a calculator makes me a mathematician.

People of Product is brought to you by Crema - a design & technology consultancy

Nathan Ott, Chief Polisher and co-creator of the GC Index, has spent over a decade measuring what he calls an “organimetric” on energy for impact. Hear why being skilled at something doesn’t mean you’re energized by it, and how understanding where your team’s energy goes depersonalizes friction. The aha moment happens when you develop awareness of your product team members’ wiring, not just your own.

Self-awareness vs. other-awareness

Personality tests are great for self-awareness. They help you understand yourself. But where they fall short is “other-awareness” or understanding how to work with others effectively.

“We value people for what they do, not what they intend,” Nathan explains. “We see their actions, their personality, their learned behaviors. But it doesn’t get to where their intentions are.”

The GC Index measures something different: how people are energized to contribute. It surfaces the real intentions driving someone’s behavior at work. When you understand that your colleague is energized by making things brilliant (high polisher), their critical feedback isn’t personal, it’s simply how they see their work.

The 5 proclivities

The GC Index measures proclivity, not to be confused with preference. Preference suggests you have a choice in the matter. These are the five ways people are naturally energized to make an impact:

• Game Changer - Generating breakthrough ideas that could transform the business

• Strategist - Making sense of complexity and creating clear direction

• Implementer - Executing plans and getting things done

• Polisher - Refining and improving to achieve excellence

• Play Maker - Bringing out the best in others through collaboration

[See if you’re eligible for a free assessment with Crema]

You get a score from 1-10 on each. A score of 1 doesn’t mean you’re bad at it — it means don’t leave you there alone for too long. High scores aren’t always good, and low scores can be strengths depending on what the work requires.

When you walk through the door at 9am on Monday morning, you have a go-to energy to do something. That’s all the GC Index picks up on.

Skilled doesn’t mean energized

Here’s a common misunderstanding leaders have that could actually be harmful. They assume that because someone is technically excellent at something, they should keep doing it.

You could have a skilled product manager who facilitates stakeholder meetings and builds consensus across teams. They’ve developed those capabilities over years. They’re good at it. But if they’re actually wired as a Strategist who gets energy from making sense of complex problems, spending 30 hours a week in meetings coordinating people could wear them down, (even though they’re good at it).

When work drains you rather than energizes you, you’re running on willpower instead of natural momentum. That’s sustainable for short bursts but exhausting long-term. Skills matter. Experience matters. But energy reveals whether someone will thrive or just survive in a role.

Depersonalizing friction

An aha moment comes when teams finally make sense of friction that’s been happening. When you know your CMO is energized by making things excellent (high Polisher) and won’t settle for good enough, their critical feedback isn’t about you, it’s how they see their work. When you know someone is energized by seeking clarity (high Strategist) before moving forward, you stop taking their questions as obstacles.

“It’s not personal,” Dan Linhart (GC-ologist) explains during the episode. “You’re not doing this because you’re just that way. You’re doing this because you intend, you wanna make things perfect. That’s how you see your work if you’re a polisher.”

Nathan puts it even more directly:

“If we didn’t have the GC index, the conversation would be based on personality. You’re stupid, you don’t understand, you’re not listening, you think you know it all, whatever it should be, yeah? Those sorts of things. Words we can go, you’re all a bunch of strategists. You’ve all got a fixed view of the world, but you’re gonna have to get aligned... And it just takes the personality out of it, see? Much easier.”

That’s the real power! Understanding the intentions behind the actions removes the personal sting from team dynamics.

The wrong energy in the right role

Product leaders constantly look for ways to optimize teams and work better together. But hiring someone for a role based on skills alone, without understanding their energy for impact could be a ticking time bomb.

You need a developer to be strategic and look ahead, but they’re energized by writing really quality code (high polisher, high implementer). There’s nothing wrong with them — they’re just the wrong energy for what you need. You can’t bank on someone succeeding in a role when their proclivities aren’t aligned with what the work requires.

A real world example from Nathan…a European bank was rolling out a global procurement system upgrade. They hadn’t embedded version one well — it was buggy, with lots of issues and customer complaints. But everyone on the leadership team was busy looking at version two.

When they profiled the team, it became clear: 85% game changers and strategists. Excited by new ideas. Excited by the future. No one was paying attention to version one, which desperately needed implementing and polishing.

The solution was straightforward once they could see it, they needed to segment the team. Put the game changer and strategist energy on version two. Put the implementer and polisher energy on fixing bugs and embedding version one.

Recap

Understanding what the GC Index doesn’t measure is just as important as what it does:

1. It’s not personality - The GC Index won’t tell you if you’re introverted, extroverted, agreeable, or conscientious. Those matter, but that’s not what this measures.

2. It’s not skills - It won’t tell you if you’re good at your job or what capabilities you’ve developed. Skills and experience still matter—the GC Index just tells you what energizes you when you show up to do the work.

3. It’s not meant to work in isolation - The GC Index is most powerful when used with other data, processes, or projects. If you have a project methodology, innovation process, or change framework, integrate the GC Index with it. One plus one makes three when you combine energy for impact with how you already work.

People of Product is brought to you by Crema - a design & technology consultancy

Description: Cybersecurity service companies love reselling the same tools everyone else has. Francisco Donoso, Chief Product and Technology Officer at Beazley Security, knows that’s a trap. He’s spent his career championing products inside service organizations—not for vanity, but to actually set companies apart in this crowded market. In this episode, Fran explains how to do that well.

Why build when you could resell?

Most security service providers take the reseller route—mark up third-party tools, deliver the service, collect the check. Everyone’s selling the same thing with different logos. Fran’s approach is different.

“Investing in technology and products that enable clients to see real time what we’re doing on their behalf really highlights that value. It shows them that we’ve got the processes and the solutions and that we’ve invested in the technology to accomplish those objectives.”

Building proprietary client-facing products does two things: it sets you apart in the market, and it forces you to operationalize your backend processes in ways that scale. If you can’t show clients what you’re doing through a portal, you can hide operational cracks. When you build the portal, those cracks become impossible to ignore.

The SLA mistake that changed things

Early in his career, Fran built a product that put service level agreements front and center for security analysts. Seemed brilliant at the time. The unintended consequence? Teams optimized for speed over quality.

“Our team was very focused on how quickly are we delivering rather than what’s the quality of what we’re delivering. Unwinding that took a long time.”

The lesson: when you codify assumptions into software, changing course becomes significantly harder than it would be in a traditional service model. Experience, Fran says, is just knowing all the mistakes you’ve made before—and making new ones instead.

Actuarial data beats snake oil

Working for a company owned by a cyber insurance provider gives Fran something rare: actual data on what drives risk. Not vendor marketing. Not conference hype. Real claims data showing what causes breaches and losses.

“We have an opportunity to say what’s actually driving risk, what’s driving claims, what’s driving losses for companies, and then say, how do we build solutions to prevent that?”

This is the most unique position Fran’s been in during his career. The incentives are aligned—clients don’t want breaches, Beazley doesn’t want to pay claims, and Fran’s team builds products to reduce actual risk based on evidence. No snake oil required.

The promise and peril of AI in security

Fran describes himself as “somewhat of an AI skeptic” - though he uses it daily and thinks you’d be silly not to. His skepticism comes from seeing both sides clearly.

On the risk side, he’s watching things like Model Context Protocol (MCP) servers introduce new attack surfaces. His security research team is actively working on research about breaking these systems. “A lot of these MCP servers are a total mess from a security perspective. And they’re just going to lead to some really interesting and quite frankly terrifying breaches.”

But he’s also building with AI. His team is working on domain-specific large language models augmented with Beazley’s proprietary insurance data. The foundational models are “super cool as an end user, to be honest, like to just be able to chat and riff.” But the real opportunity? Models trained specifically for cybersecurity domains where you can reduce hallucinations and rely on decision-making for automation.

On whether AI will let anyone build SaaS products? Fran thinks people are “likely discounting the amount of maintenance and work that comes into upkeeping a product once it’s launched.” Burning down tech debt, rearchitecting backends for features you didn’t know you’d need—that’s the invisible engineering work. “So I think we’re quite a ways away, but I also see how quickly this AI stuff is advancing. I can’t place my thumb on it. Right now we’re not there.”

His take on big tech’s “AI is replacing engineers” narrative? It’s business reality driven by economics. Companies need money to invest in the AI race, so they offset costs by reducing headcount. But friends at those companies tell him they’re just pushing the same work to fewer people. The reality doesn’t match the marketing.

Product people, not managers

Fran started as an engineer before a CEO told him he was actually a product person. The realization: product is about communicating with stakeholders, understanding market needs, and building solutions for humans.

“People are the hardest thing about technology. Technology is easy. People are incredibly challenging and hard.”

His advice on building products? Stop overestimating the value of what you’re building. Launch something imperfect to validate assumptions. The worst feeling as an engineer is building features no one uses—and Fran’s been there enough times to know better now.

In this episode, Mark shares what he learned from talking to 120 CISOs in a six month period, why proximity to customers creates velocity that big teams struggle to achieve, and more.

The dangerous gap between “like” and “buy”

It’s safe to say that Mark’s career has given him a well-rounded perspective. He’s built products, sold products, serviced products, and advised on products in the cybersecurity space. This 360-degree view has made one tough, but important truth obvious:

“People can say that they like what you do, but that’s very, very different than them getting out of their pocketbook and spending money on it. That is two different scenarios, completely different scenarios.”

This is how it goes in many social or professional settings - people are nice. They will be supportive, offer suggestions, say that it’s great and never buy. Mark learned to find design partners who would be brutally honest about budget, replacement vs. net-new spend, and whether they’d actually pull the trigger.

120 CISOs in six months

When building Secure Blueprint, Mark didn’t send out async surveys or run a few user interviews. He talked to 120 CISOs over a 6-month period. It’s worth noting that in these conversations, he wasn’t asking about UI preferences, he was mapping their operational reality:

• Budget cycles and how they allocate CapEx vs. OpEx

• How they report progress to boards

• How products fit into maturity assessment processes

The goal is to understand if your product would be integrated into daily workflows or become a “once a month nice-to-have.” The former gets adopted. The latter gets churned.

The vaporware market

With 10,000+ cybersecurity products in the market, Mark sees a bit of an ugly pattern. There’s quite a bit of ‘buzzword bingo’ and empty promises make it nearly impossible for customers to identify real innovation.

“You can have to wade through all of the vaporware. And when you sort of peel it back, there’s nothing there. Literally, like there’s nothing there. Or what they claim is literally not accurate.”

Everyone is slapping “AI-powered” or “cloud-native” on their pitch decks. CISOs wade through pitch after pitch, and even 25-year industry veterans like Mark get confused by the marketing fodder.

Simplicity could be your competitive advantage

CISOs speak one language to their technical teams and another to the board. If they can’t translate your value prop up the chain for budget approval, your product dies.

“The more you simplify things, the more you can amplify things. If you overcomplicate things because it’s a tech sell, then as soon as the technical seller goes up for budget, you lose translation.”

Proximity to customers creates velocity

Mark has led both massive teams and small ones. His current approach at Evolve favors small, senior teams — not because small is necessarily better, but because proximity to customers creates speed.

“The more layers you have, the further away they are to the customer and the farther away they are to the purpose.”

When developers see client data in real-time and make decisions based on what’s happening right in front of them, they don’t wait for tickets. They solve problems.

TL;DR: Build at the intersection

Cybersecurity products succeed when they balance technical depth, business viability, and operational reality. Stay close to customers, simplify ruthlessly, and know the difference between someone thinking something is interesting vs. handing you a credit card.

People of Product is brought to you by Crema - a design & technology consultancy

From engineering leadership to his first product role at a pre-seed startup, Aaron shares how emotions signal professional values, why balanced teams outperform individual expertise, and how trust is built through daily consistency rather than grand gestures. This is a testament for product leaders who see fear as information rather than an obstacle in the way.

Fear as a kind of north star

Most people run from fear, but Aaron Nordyke has learned to follow it. He’s learned, especially over the last couple of years, that emotions are our friends. They’re trying to tell us something, trying to tell us what we value.

When his former boss offered him a product role despite having very little product experience, Aaron’s first instinct was panic. But he’s developed a different relationship with that discomfort:

“I would use that fear to guide me toward learning as much as possible. I would grab what people consider the industry standard books, and I would pour through them and practice them.”

This isn’t about being fearless! It’s about being fear-informed. For product leaders constantly facing the unknown, Aaron suggests looking for the opportunity to turn the anxiety into action. It isn’t always easy or natural, but it’s a positive and necessary response.

The art of seeing and lifting others

Drawing from Carl Jung’s concept of the “King Archetype,” Aaron has developed a leadership philosophy centered on recognition rather than being recognized.

“King energy is not about being seen. It’s about seeing others. You get out there specifically to see others, to see excellence, and to honor that excellence and lift it up.”

This translates into specific practices, like monthly skip-level meetings where you could tell you group things that are impressing you, that certain people are doing. The goal is providing encouragement:

“If you tell somebody that what you’re doing is what I want you to continue doing. That is constructive feedback that gives them certainty they are on the right path.”

Aaron believes that this approach addresses a universal truth: Where everyone is a beginner, everyone is a little bit scared. By creating space for people to feel safe in their uncertainty, he’s seen teams consistently flourish across different technical domains.

Trust as your only currency

In the high-stakes world of startups, Aaron abides by Reid Hoffman’s definition of trust: “consistency over time.” This isn’t about grand gestures, rather, it’s about daily deposits. Every single time that you meet that expectation, a trust deposit is made. “You’re putting a marble in the jar,” referencing Brené Brown’s marble jar concept.

For early-stage companies like Drypowder, this patience can feel counterintuitive. “Unfortunately, we’re not very patient when we’re trying to fundraise and get our early customers.” But Aaron understands the math: “You can’t withdraw from something that they don’t know.” In other words, you have to make trust deposits before you can ask for customer feedback, team commitment, or investor confidence.

The compound effect is powerful. When you’ve built that consistency, you can expect that it will be done again. In a world where everyone can create products, trust becomes the ultimate differentiator.

TLDR;

Fear isn’t your enemy! It’s your compass for professional growth. Build teams around complementary strengths, not individual perfection. Create certainty for others by consistently recognizing their excellence. And remember: trust is built through daily consistency, not grand gestures.

People of Product is brought to you by Crema - a design & technology consultancy

Redefining "fail fast" for your product team

The concept of "failing fast" gets thrown around a lot in product circles, but Meg discovered something important: her team needed explicit permission to actually do it. Despite intellectually understanding that not everything would work, they were unconsciously seeking guaranteed wins instead of taking the intelligent risks that drive innovation.

"We have had a lot of discussions as a product organization recently about what does it mean to fail fast? What does that look like? How does that show up?"

So what does it look like? Sharing when it happens, celebrating it, and learning from it together. It's not about seeking out failure, but it can be an intentional exercise when we know the outcome will never be perfect. If you're not failing, you're not trying.

As Meg put it… Let's ski hard! We're gonna fall down and that's okay.

With her team she openly communicates that failure is not just acceptable, but expected. And that has made all the difference.

"One of the observations that I made to myself when we were having that conversation is I think that they needed to hear from me that failing was expected and it was okay."

The unspoken pressure of perfection

Even though she knew that not everything would work (having come up through product management herself), her team was feeling pressure to make everything they touched perfect.

The fix wasn't terribly complex, but it required intentionality: "Tell your teams it's okay to fail and that actually you want to hear about it, you're gonna celebrate it, and that it's expected as part of their role."

This isn't about seeking failure for its own sake. As Meg puts it:

"Not that we're seeking out things that we know will fail, but we learn from those lessons. It's an intentional exercise to see the outcome. And when the outcome is not perfect, we modify the strategy, we take a different approach, and we go back to the drawing board."

Strategy as a living thing

This mindset shift from perfectionism to learning extends beyond individual projects to how Meg thinks about strategy itself. Rather than treating it as a static document created once per year by leadership, she advocates for something far more dynamic and inclusive.

At RX Savings Solutions, they've implemented quarterly strategy sessions with their extended senior leadership team. It's about 60 people including product managers, engineering leaders, and their direct reports, asking questions like: Are we still on track? What's changed, what's possible, how are we trending to milestones? More than a check-in, it's an opportunity to course-correct based on real market feedback and execution learnings.

A key insight worth sharing: the people executing the strategy need to be involved in evolving it.

"The market insights and the market intelligence and the client feedback and all of those components that as a product organization we should be doing should drive the strategy."

Leading change when you love change

Another relatable challenge Meg shared was learning to manage her own enthusiasm for change. She is absolutely excited by and okay with change. In her own words, she’s the first one on the bus and she’s driving. But being a change enthusiast in a leadership position requires restraint and empathy.

"I have had to check myself and take a step back and say, you've gotta bring others along. Others need me to bring them along, tell them why I'm so excited."

This tension between moving fast and bringing people along is one of the core challenges of product leadership. The solution isn't to slow down, but to invest more heavily in communication. Setting the context over and over again.

Tech hasn’t solved the apparent communication crisis

Despite all our collaboration tools and communication platforms, communication consistently shows up on every company's improvement list.

"Everywhere I've ever been, communication and collaboration are always on the 'we need to fix it' list.”

Her insight is that tools alone don't solve this. It requires intentional practices and, importantly, moving beyond just sending information to actually ensuring understanding. The difference between "I sent the requirements" and "we discussed and aligned on the requirements" is the difference between activity and value creation.

TLDR;

Meg's approach to product leadership centers on three key principles:

1. Creating psychological safety by explicitly giving permission to fail and learn

2. Treating strategy as collaborative and iterative rather than top-down and static

3. Investing time and intention in communication that goes beyond just info transfer

These aren't groundbreaking concepts. The magic is in the execution and the discipline to maintain these practices even when things get chaotic.

As she wisely noted: "If you want to be innovative and create real change, you have to be comfortable with pain. But hopefully the outcomes we're all searching for—more certainty in projects, safety protocols—those are outcomes people really want."

People of Product is brought to you by Crema - a design & technology consultancy

Lean fully into the “value creator” mindset

Jason doesn't love the title "product manager" - and he’s got good reason. He's seen too many people fall into the trap of simply managing activities. It’s ironically one of the primary reasons PMs like differentiating themselves from project managers. But how well are we doing this as an industry?

“I don't want people to be a manager. I prefer just the term value creator, because that's what I expect people to pursue. I want you to create the fastest path to the most value. And what that means is you have to understand the user need you're solving for, and ultimately the value that you're creating for them.”

Activity does not equal benefit or value. As Jason reminds us, product managers can get endorphins by going down the checklist, but that does not mean that what you're actually doing is creating value for the end user.

2 traps that inhibit product excellence

• Letting others interpret your data - Whether it's qualitative feedback from users or quantitative insights from analytics, Jason believes product people need to get their hands dirty. "You need to be the one who is exploring the data and really pulling the thread in Domo or Mixpanel... You have to be there. You have to get your hands dirty."

• Using AI as just a tool - The mistake isn't using AI, it's thinking of it as just another tool. Really unlocking AI comes from thinking about it the same way you would a teammate or a collaboration partner.

Innovation = Proximity + Speed

Jason thinks of innovation as being relatively simple.

“If you take the people who are solving the need and you get 'em as close to the customer as possible, and then you shorten the iterations... then that, to me is really how you innovate. Because you're staying really close. You're listening and you're releasing a lot."

Even in enterprise environments, Jason advocates thinking like an entrepreneur. "I strongly believe that even if you're working for a large enterprise, you've gotta think like an entrepreneur. You've gotta think small."

Building psychological safety

Drawing from Google's Project Aristotle research, George & Jason talk about how the perfect teams aren’t what you'd necessarily expect.

"Do you think that the perfect team had the smartest people? No. And was it the overachievers? No. It was the people who were really good at reading into other people.”

This goes back to building psychological safety - environments where people trust each other enough to take risks and speak up regardless of hierarchy. In an environment where people trust one another, guess what happens? You feel like you can take risks. You can raise a challenge, talk about what is or isn't gonna work, and why.

What's exciting about the future

Jason's most excited about the democratization of prototyping through AI. His 21-year-old son built an entire platform in six hours using AI tools, got feedback from a Reddit community, and had paying customers within weeks. Gen Z and those that follow have been born into an age with miraculous technologies, and some are seizing the opportunity to do some neat things.

"To see somebody who understands how to build software, but to then be able to create something that solved a need so quickly and get feedback on it and know the parts that it's just kind of a tool that people aren't interested in... To be able to iterate like that in days because of generative AI. That's really exciting."

People of Product is brought to you by Crema - a design & technology consultancy

Dan explains why he looks for willing business partners instead of fighting resistance, how rockstar superintendents became his best AI evangelists, and what happens when you prioritize eliminating the bane of most people's day over shiny objects.

Education over bells and whistles

Dan's approach to AI implementation at Ryan Companies flips the typical playbook. Instead of leading with sexy use cases, his team made an unexpected choice.

"One of the biggest things we did from a strategic standpoint related to AI wasn't all the bells and whistles - which use cases are you going after, what's the sexy thing you're doing right now? It was honestly communicating and educating with our company, giving them the right education, giving them a foundational understanding in order for them to rethink about their roles and rethink about how this technology will change their work. Because it ultimately will."

A three-module curriculum that he proved works

Working with the University of Minnesota, Dan built a practical education framework:

1. Hour-long fundamentals: "Give them semantics to talk about the words, to understand and read an article better. Remove that fog, the unknown unknowns."

2. 90-minute hands-on: "I have this suspicion that no one takes the time for themselves unless you tell them to do it. If I were to give them an enterprise chatbot license and say 'go take 90 minutes and tinker,' they're not going to protect that time. So we protect that time for them."

3. Design thinking workshop: "We've given individuals a new toolset and new language to think about innovation, but we haven't taught them how to innovate and change."

Finding willing partners, not fighting resistance

Dan's change management philosophy is refreshingly honest: "I truly look for partners in the business who are willing to come on that journey. There are areas where there's been resistance, and that's just maybe not where we started. That doesn't mean we won't get there, but we're trying to prioritize the partners at Ryan who are really willing to go on the journey with us."

His approach involves getting on job sites: "We've tried to engage and empathize with our business partners as much as possible—getting on the job site, having them tell us their problems, listening really intently and coming at those problems with a different perspective."

The best ambassadors aren't who you think

"The best sellers of those ideas in domains where I'm not the expert—if I have our rockstar superintendents going out and selling the use cases we have, that's going to be a huge win. I hope it's them finding the value and driving that narrative more than I am."

TLDR: Start with people, not technology

Dan's approach proves that successful AI transformation requires treating it as a human challenge first, technical challenge second. Key lessons:

• Education beats evangelism - Build foundational understanding before pushing use cases

• Find willing partners - Work with early adopters rather than fighting resistance

• Create internal champions - Your best evangelists are domain experts, not tech teams

• Protect learning time - People won't make time for AI exploration unless you structure it.

People of Product is brought to you by Crema - a design & technology consultancy

The narrative more recently is that AI will replace all developers, perhaps later this year or maybe next.

Here's why I don't believe that to be true from first-hand experience. Not just headlines. And this is coming from a CEO who is NOT a developer, so I’m not just defending my skillset.

Most non-technical CEOs only brag about the promise of AI. But I’m trying to explain where I see the real-world edges.

This is not an anti-AI post. I’m generally very pro-AI and excited about the potential future. I’m seeing the hybrid reality of where we are today and where things are headed.

Vibe coding enterprise products doesn't fully exist… yet.

From first-hand experience of vibe-coding my app (not tapping the shoulders of the Crema in-house team), just to see how far I can get on my own, progress wasn’t great. This is despite having 16 years of product/UX experience. I know the jargon, vocabulary, and basics, but not the pros and cons of architectural decisions, migration workflows, deployment approaches, etc.

Our senior developers can run laps around me in this type of work. I can't get vibe-coding to achieve the desired outcome without significant hours of testing, learning, and iterations. Far beyond the time I should be spending here.

Does that mean I'll stop? No! I'm learning where the edges are and sharing internally and externally. Also, it's fun!

So why the layoffs?

As much as all of the big tech companies are talking about massive layoffs and replacing half their workforce with AI, I would suggest that this is actually these organizations finally shedding a vanity metric of talent hoarding. Armies of individuals who waste hours deciding what color and position a button will have to squeeze out a small % KPI shift in a giant user base. Helpful? Yes.

Do you need 300 people onboarding every 2 weeks to accomplish this? No.

Yes, AI has to do with it. It’s forcing companies to ask the questions, “Do I need all these people to achieve our goals? And if I don’t… who can achieve more with less?”

Is AI being used?

Absolutely.

• Product planning

• Bug fixing

• Testing

• Code-assisting

• Code drafting

• etc.

But the question is… by whom?

There are tons of enterprise vibe coding tools on the market, right?

Yes. Yes, there are. Microsoft Co-pilot and Power Apps, Google Gemini, and a dozen more. All with the promise of designing, building, and deploying an enterprise product with quality, security, and scale.

But working first-hand with enterprises, they are testing, and they are prototyping, but they are not deploying fully AI-generated and managed apps without senior technical oversight and support.

Those getting the best results have strategic senior technical talent either orchestrating the entire experience, leveraging AI’s capabilities, or overseeing the entire end-to-end solution.

Though I would argue that the lion's share of the products hitting the market are aimed at small tech ventures or ‘solopreneurs.’ High volume, lower risk.

Security is a BIG concern for enterprises

Cybersecurity incidents are likely one of the largest threats to any technical organization, outside of macroeconomic shifts, and labor shortages. A breach or security incident can break trust with employees, clients, investors, stakeholders, and more.

Now, I would argue that to overcompensate for this, security leadership's answer to this is often to say "no" to everything. Yet, we are seeing a shift here. Many of our enterprise clients are a mix. Some are moving full steam ahead and building protocols as they build and fly the plane, and some are throttling way back and waiting for the dust to settle, but falling behind because of it. Is there a right answer? No, both have to happen. Close eyes on innovation, scale, security, and evolution.

Not exclusively, but this seems to align pretty closely with those enterprises that are tech-forward in their views of cloud computing, in-house innovation, development, and strategic investment in early venture partnerships.

The AI is not always right

While the LLM-generated code can achieve some pretty extraordinary results, it will often look for either the most popular way to do something (via its internet-trained context) or the most complex way of doing something (via its internet-trained context), and there may be a better way.

Multiple times in my vibe-coding, I found myself going in circles and not achieving the results I was hoping for, though they were inside and simple enough. It wasn’t until I suggested a more basic approach, or even went and did my own research to provide a suggestion, that the LLM finally decided it worth considering.

Why doesn't it do this well? Almost always, it’s about context. The LLM has absolutely no idea what is going on outside the code base. I am sure that if it had the context, it might be able to do it, but without this context, it’s functionally looking to achieve what it thinks you want.

A strategic developer has context

A senior strategic developer, on the other hand, not only has experience and a technical approach that he or she considers best practice, but more importantly, has real-world context.

They know that…

• In a few weeks, there might be talks of integrating a new data source. Then the current approach will have to change.

• There is a legal constraint on how often we can fetch data from that 3rd party API.

• There is a business desire to turn this in-house tool into a multi-tenant SaaS product one day.

• The employee users have been using the same spreadsheet for 5 years, and don’t actually want this software yet.

• The company doesn’t have any customers yet, so they need to get to revenue sooner rather than later.

• They just acquired their competitor, and in 3 months, they are going to integrate 2 companies’ data into one solution.

• They know that the guy who wrote the original app is very proud of his work, even though it’s built on libraries that were sunset 5 years ago.

LLMs binge on context to get the best results. It might seem like magic at first, but they are desperately scrounging for memories to shape around a user and their context. But feeding, training, and tuning all this context is a technical beat and feat in and of itself.

So what?

So… bring your strategic developers to the table and keep testing AI!

• Listen to devs concerns.

• Challenge their challenges.

• Name the desired outcomes.

• Equip them with best-in-class tools.

• Test and test again. The tools will get better, make sure you’re people do too.

A conversation for another day

So what about junior talent?

Need help with that product and strategic oversight with your in-house innovation?

Schedule a time to talk with me about a product team assessment.

https://calendly.com/crema-george/product-team-assessment

Thanks ya’ll!

-George

The new reality of product teams

Julia's perspective comes from leading AI and experience teams at Zillow, where she's witnessed firsthand how rapidly evolving tools are reshaping what it means to build products. The traditional boundaries between roles are blurring in ways that require teams to develop new patterns of collaboration.

"I think across tech it's clear that our roles are becoming more pixelated," Julia explains. "An engineer can be product minded or spin up their own spec, and a designer can code. That is great, but it does require practice in how to do that day to day and redefining your way of working with your partners."

When everyone can prototype, what happens?

The democratization of building tools has created unprecedented opportunities for rapid experimentation. Julia describes building a prototype at 40,000 feet during a flight, responding to feedback she'd received from real estate agents earlier that day. This kind of immediate iteration would have been impossible just a few years ago.

But this accessibility comes with a caveat. While anyone can create a demo or proof of concept, getting something to production quality remains a significant challenge. The gap between "it works in the demo" and "it works reliably for thousands of users" is where product sense becomes crucial.

The 3 work postures that still matter

• Asking good questions - Good judgment starts with good questions! Stay curious.

• Exercising judgment - When you can spin up a deep research report in a matter of minutes, discernment becomes imperative. What can be trusted? What should you use? What should you ignore entirely?

• Taking agency - The tools are there, but they require someone willing to dive in without waiting for permission. High agency product people are experimenting, learning, and iterating faster than they ever have.

2026 predictions

Julia predicts 2025 will be "the year of messy AI tech" where everyone is piloting and experimenting, with 2026 being when things start falling into place. This mirrors the pattern we saw with multimodal AI exploration in 2023 and broader implementation in 2024.

For product teams, this means the current period is about building muscle memory around new tools and workflows rather than expecting immediate perfection.

This is the worst that AI tools will ever be!

TLDR; Having product sense is the differentiator

When everyone has access to powerful building tools, the ability to know what to build becomes the key differentiator. Product sense - that combination of customer empathy, business understanding, and strategic thinking - becomes more acute when the barriers to creating are lower.

The message is clear! Embrace the fluidity, be ready to develop new collaborative processes, and remember that all the tools in the world can't replace good judgment about what customers actually want.

People of Product is brought to you by Crema - a design & technology consultancy

They’re chasing the loudest voices instead of real impact.

They’re getting distracted by shiny objects like AI.

They fail to solve incongruencies between various areas of their organizations before executing.

Mark Vanderweide, Chief Product & Technology Officer at Bungii, has seen this play out across startups, enterprise organizations, and M&A deals. In this episode, he breaks down how great product leaders fight the noise, focus on real value, and align teams before things spiral out of control.

Additional topics include:

• the difference between buyers and users and why it matters

• key takeaways from Mark’s experience in product management in different company sizes

• how to navigate the challenge of aligning newly acquired teams and leadership

• managing competing interests from sales, ops, engineering, and leadership

• AI hype vs. practical use cases

• what separates high-performing product teams from dysfunctional ones

People of Product is brought to you by Crema - Get the most out of your existing product teams.

Nate Juraschek, Head of Product at Telarus, has spent 20+ years navigating the highs and lows of product leadership—from Sprint and H&R Block to fast-moving startups. Along the way, he’s learned one truth: data is only as good as the story you tell with it.

Topics covered in this episode include:

• How to use data as a guide when following gut instincts

• Why curiosity is the secret weapon of great product leaders

• The most powerful (and underrated) analytics tools to start using today

• How a background in filmmaking prepared Nate for the world of building digital products

• How AI is changing the way we track, analyze, and act on product data
  

Whether you’re in product, UX, or tech leadership, this conversation is rich in insights to help you make more confident decisions.

Watch the full episode on YouTube

This episode is brought to you by Crema - Get the most out of your existing product teams.

In this episode, Pat tells the story of how Digs came to be, and how he pivoted from pursuing architecture as a career to following a new interest in real estate, fintech, and educating first-time homebuyers when they needed it most.

He takes us through the challenges and successes of scaling, fundraising, and eventually exiting through an acquisition.

Additional topics:

• Transitioning to a for-profit model

• Building the Digs team

• Navigating COVID and fundraising uncertainty

• Team dynamics and scaling

• Joining MoneyLion and building influence in a new organization
  

Join the conversation! 👇🏼

What unexpected skills or experiences from your past have shaped the way you approach challenges today, and how might hidden lessons from your own journey fuel future innovation?

Leave a comment

People of Product is brought to you by Crema - Get the most out of your existing product teams.

In this week’s episode, Alicia shares her insights on building a culture of innovation, aligning it with company goals, and emphasizing the strategic importance of fostering collaboration across departments.

Topics covered:

• defining innovation in the workplace

• fostering a culture of innovation

• AI and digital twins

• challenges and future of innovation

• the role of change management in innovation

In this week’s episode, we dive into the challenges of user adoption of new tools, the importance of understanding the end user, and the ethical questions surrounding AI.

Other topics covered include:

• the role of AI in data management

• the ethics of AI and technology resistance

• effective engagement with tech companies

• building strong relationships in tech

How many technology leaders have gone out looking for a software vendor somewhere in the world with an RFI or RFP asking for a fixed-scope contract to include a specific number of features, only to either be ultimately disappointed with the result or upsold dozens of change orders when reality sets in?

Fix-scope contracts are rewarded because they are black and white. They give the illusion of de-risking for the buyer. But they are almost always without alignment around the correct outcomes, quality, and norms of working, and have no way of accounting for the unknown unknowns that are guaranteed in every software development initiative.

Fix-scope software contracts are guesses.

In my 17 years in this industry, I have seen maybe one or two very specific products where the product owner knew exactly what their product should look like, what it should do, how it should respond, how much it would need to scale, where it should start, and possibly what features it would grow into... before a line of code was written.

The ones that did were extremely simple in functionality—like a one-trick pony. (It’s amazing if you can find something like this that hasn’t already been done.)

99.99% of software, apps, and digital products are large guesses at the start.

Hypotheses on features, use cases, integration needs, deployment scenarios, data management, device support, mission-critical starting points, and level of value to the user, etc.

There are some exceptions to this.

For example, WordPress websites based on a template, or a platform reseller that does simple integrations to make their product fit the user’s minor adjusted needs.

This is not what I’m referring to.

I’m talking about innovative, potentially disruptive, or even competitive solutions in a crowded "me too" market/user space, where everything seems obvious, but you want to catch up and surpass your competitors or the existing solutions in the market. This is always more complex than you think.

Building your own digital products is about addressing a unique set of challenges or needs.

By their very nature, this means there are many unknown unknowns.

This could be as simple as where to have a modal open, or it could be about how to handle sockets for real-time collaboration with hundreds of users simultaneously in an interactive canvas while prompting a privately hosted LLM in your own container for privacy and security, all while training your custom model on top of the foundational model so that you can create dynamic, personalized experiences for your users that meet their unique needs instead of generic ones.

Sure, the second scenario seems like a complex one, but if the modal doesn’t open in the right place at the right time, then the user may never experience that dynamic feature set.

But the contract said…

So, do we put in the contract that your app will include all these features, plus all the default app functionality, plus the color of the button that will get their attention enough to open that modal to access the LLM model that we plan to train but have not yet trained so that we can achieve the dream state we have in your mind?

No, of course not.

Instead, contract a team with a shared set of goals.

Why this, why now, for whom, and with what outcome?

We set constraints and identify what is driving those constraints: budget, a fixed date (year-end, conference, large project kickoff), team size and skills, dependencies, infrastructure, etc.

Then we align the team. This is the most important part.

What are WE here for?

What are each of our roles?

Why are these skills needed?

And how might this change over time?

Finally, what will success look like?

It is not merely to launch. While this is a feat in itself, it’s not the goal.

The goal is engaged and deliver value to users who are better off because what you built is part of their lives.

Be mindful of assuming that a PRD (Product Requirements Document) for an RFI/RFP is going to get you to that state.

Assume you know very little, and then contract, hire, or acquire a team that is rowing in the same direction to prioritize what matters most, when, and who is flexible enough to learn, collaborate, communicate, and adapt as they move forward within those constraints.

Agree to a better contract.

When looking to contract software there are a few options.

1. Staff Augmentation

   Find a company that can resource you with individual team members and you build a team. This team will need to be managed. Either self-managed or by the product manager. And they should have access to resources and other stakeholders to make sure they are not operating in isolation. Consider, UI Design, Testing, Front End development, API and Data architecture, or full stack.
   
   These contracts are often billed on the hour or on a retainer. They can also be staffed into FTE over time with a management and/or finders fee.

2. Product Teams (Squads)

   The benefit of a squad approach is often their ability to work together well already.
   A product team will include all of the roles mentioned above or can blend with those roles if they already exist in the organization. A Product Team agency will handle staffing all roles, setting team norms, integrating with internal and external stakeholders, and managing constant communication between everyone.
   
   These contracts tend to be time and duration. A weekly, sprint-by-sprint, or monthly burn rate, with the constraint of duration on the project.

Check out Crema

Crema is a design and technology consultancy. For 15 years we’ve been fully integrating product teams with our clients to design and build technology and technology teams. Crema aligns leadership, explores possibilities, prototypes ideas, validates with users, designs scalable systems, and builds software solutions that help companies make money, save money, and grow fast!

• Challenges with technology adoption

• The importance of proximity

• Generational shifts in the industry

• Technologists in the field

Brought to you by Crema - Get the most out of your existing product teams.

• the shifting perspective of working a trade

• the role of technology in client experiences

• safety and efficiency in construction

• looking outside of the AEC industry for construction tech solutions
  

Brought to you by Crema - Get the most out of your existing product teams.