Category: With a Perspective

  • Don’t Say Startups Are Hard

    Don’t Say Startups Are Hard

    I’ve come to believe that founding something can be one of the best things you can do for yourself during your working life.

    Not because you’ll necessarily build a billion-dollar company. Not because you’ll raise venture capital, have a big exit, or even succeed in the conventional sense. But because the experience of taking an idea and trying to turn it into something real changes you. It forces you to learn, adapt, take ownership, and discover capabilities you might never have needed to develop otherwise.

    And yet, I meet a lot of smart, capable people with genuinely good ideas who never try.

    One reason, I think, is that we founders have become very good at telling everyone how hard it is.

    When I was founding—or had just started—DataIAm, I made a point of meeting other founders. I met many, and I learned a tremendous amount from them. They were generous with their time and advice, and I’m grateful for it. But many also wanted to prepare me for just how hard the journey was going to be.

    Some told me they had reached points where they literally cried. Others talked about moments when they regretted becoming founders, or how much they had sacrificed—the time, the stress, the financial uncertainty, the impact on the rest of their lives.

    These weren’t people trying to discourage me. Quite the opposite. They were sharing hard-earned lessons and preparing me for what might come.

    But as I went further into my own journey, I kept waiting to feel some version of what they had described.

    I didn’t.

    That doesn’t mean building DataIAm has been easy. Far from it. There have been setbacks, uncertainty, long hours, things that didn’t work, things that took much longer than expected, and plenty of moments when I’ve had to rethink the plan.

    But regret? No.

    And I’ve been thinking about why.

    The closest analogy I can find is something else I spend time doing: working out.

    Nobody goes to the gym because it’s easy

    A good workout is hard. You make time for it when you’d rather be doing something else. You control your diet. You push your body beyond what’s comfortable. Sometimes you add weight when the current weight is already difficult. Sometimes an exercise that worked well for months stops producing results, so you have to find another way to challenge yourself.

    You experiment. Change the weight. Change the repetitions. Change the exercise. Learn a new technique. You adapt.

    Building a startup feels remarkably similar.

    Something that worked with beta customers may not work with others. The product you were convinced people needed may not be quite what the market wants. You run short on resources. A competitor changes the landscape. A new technology suddenly makes possible something that wasn’t possible six months ago.

    So you adjust. You learn, build, throw things away, rebuild, and find another way.

    Of course that’s hard.

    But here’s the thing about a workout: the effort starts paying you back almost immediately.

    The return doesn’t begin when you reach the goal

    When I go for a run, I don’t have to wait until I’m faster to get something from it. When I go to the gym, I don’t have to wait until I’ve gained muscle to decide whether today’s workout was worthwhile.

    The visible results come much later, but the mental reward is immediate: the satisfaction of pushing yourself, the feeling when you finish something difficult, the small realization that you did something today that you couldn’t—or wouldn’t—have done before.

    Nobody else may see any of it. But you experience it. The payback is already there.

    And I think that’s why I’ve never related to the idea of regretting the effort of building a startup.

    The startup is paying me back while I’m building it.

    Most startup returns are invisible

    From the outside, we tend to measure startup success through visible outcomes: revenue, funding, headcount, valuation, acquisition, IPO. Those are the long-term, visible gains.

    But founders experience hundreds of smaller, mostly invisible returns along the way: the first time someone you don’t know uses something you created; the first customer who gives an unsolicited shoutout; the first time an idea that existed only in your head becomes a real product on a screen.

    It’s the problem everyone thought would be difficult that your team finally solves. The moment you realize your original idea was wrong—and that you’ve figured out a better one. Watching someone on your team grow beyond what either of you expected. Learning a technology, an industry, a sales motion, or a part of business you knew almost nothing about a year earlier.

    And sometimes it’s simply figuring out how to get around the latest obstacle.

    Most of these moments won’t make a headline. They probably won’t make your LinkedIn feed either. But you know.

    That’s the part of entrepreneurship I don’t think we talk about enough.

    An exit isn’t the only reward

    We have a tendency to tell startup stories backward. Once a company becomes worth billions or gets acquired, we look back at all the struggles and sacrifices and say, It was worth it.

    But what if there isn’t a billion-dollar outcome? What if there isn’t even an exit? Was all that effort somehow wasted?

    I don’t think so.

    That would be like saying years spent exercising were worthwhile only if you eventually won a bodybuilding competition. The workout was doing something for you every single day.

    So is building something.

    You learn how to operate with incomplete information. You learn to sell, build, and persuade people to believe in something that doesn’t fully exist yet. You learn to make decisions when nobody can tell you the right answer, and to recover when something you were certain about turns out to be wrong.

    Perhaps most importantly, you discover what you’re capable of when there isn’t a large organization around you providing the structure.

    Those are returns too.

    Build something once

    This is why I’ve come to believe that, for many people, founding something at least once can be one of the most valuable experiences of a career.

    It doesn’t have to be the classic Silicon Valley venture-backed startup. Build a lifestyle business. Start a consulting practice. Create a nonprofit or a philanthropic project. Build a small product around something you understand unusually well.

    Take an idea you care about and try to turn it into something real that didn’t exist before. Find your version of it.

    Will it require sacrifice? Almost certainly. Will there be moments when you have to push beyond what feels comfortable, change direction, learn something new, or find another way when the obvious approach stops working? Absolutely.

    That’s also what happens when you train seriously.

    But we don’t tell people not to exercise because exercise is hard. We tell them what it can do for them.

    Maybe we should talk about entrepreneurship the same way.

    When founders tell you how hard it is, listen to them. They’re probably telling the truth. I certainly don’t want to minimize what any founder has experienced—or the very real sacrifices some have had to make.

    But don’t stop listening at the word hard. And if you have an idea you genuinely believe is worth trying, don’t let someone else’s horror story become the reason you never find out what you could have built.

    Because the reward doesn’t begin when you raise money, reach profitability, or get an exit.

    Just like a good run or a hard workout, the effort can be part of the reward.

    The payback can start today.

    And once you see it that way, the question becomes:

    What’s to regret?

    ————————————–

    To learn about my startup, visit: https://dataiam.com

    Zeb Mahmood

    Zeb Mahmood Co-Founder & CEO DataIAm

  • Why We Built DataIAm for FSC

    Why We Built DataIAm for FSC

    Enterprise integration wasn’t supposed to be the hard part. At least that’s what I thought when I joined Salesforce Industries in 2016.

    Before Salesforce, I worked on enterprise integration products at IBM Cast Iron and SnapLogic. By the time I joined Salesforce Industries, I knew the enterprise integration landscape well. Integration platforms (ETL and iPaaS) are incredibly capable. They connect virtually any system to any other system, support hundreds of connectors, and provide powerful transformation capabilities. They solve an enormous range of enterprise integration challenges—and they solve them well.

    I left Salesforce after nine amazing years, but I stayed closely connected to the ecosystem. I continued attending Dreamforce and following IdeaExchange, community discussions, and industry conversations.

    One theme kept surfacing:

    Data integration was slowing down Financial Services Cloud implementations.

    At first, I was confused.

    The integration technology already existed.

    So what was the real problem?

    I soon realized I was asking the wrong question.

    The biggest challenge wasn’t how to move data—it was capturing and productizing the implementation knowledge behind it.

    Take a typical Financial Services Cloud (FSC) implementation at a bank. One person understands the core banking system—whether it’s FIS, Fiserv, Temenos, or another platform. Someone else understands FSC’s data model. Another person knows how to configure and use the integration platform. The knowledge that connects those worlds—field mappings, business rules, and data fixes—is assembled for that specific implementation, but is rarely packaged in a reusable form for the next customer.

    The next implementation team often starts from scratch.

    That was the insight that changed the way I think about enterprise integrations.

    Many enterprise applications repeatedly connect to the same systems.

    Core banking systems and FSC are a good example.

    That led me to a simple question.

    What if enterprise applications came with purpose-built integrations for the systems they connect to most?

    Some integration patterns are repeated so frequently that they deserve to be productized.

    Salesforce has built an incredible suite of products and an equally incredible partner ecosystem. I saw an opportunity to contribute to that ecosystem by building Salesforce-native integrations that feel like a natural extension of the platform.

    We believe repeatable integration patterns shouldn’t require repeated implementations.

    Once I became convinced this was worth pursuing, I also knew there were people who understood parts of the problem better than I did. I sought guidance from a former SVP of Engineering at MuleSoft to help shape our thinking around enterprise integration. I also brought on a former SVP from FIS to ensure we were grounded in real-world core banking knowledge. Throughout the product’s development, we worked closely with the Salesforce Financial Services Cloud team to validate ideas, refine priorities, and ensure the product complemented the Salesforce ecosystem.

    That idea became DataIAm for FSC.

    Instead of asking every implementation team to recreate similar field mappings, data fixes, and synchronization logic, we built those assets into the product. Customers begin with prebuilt assets that dramatically improve time-to-value. Where their requirements differ, they can configure and extend them instead of starting with an empty project.

    We also made a few deliberate design decisions.

    First, we built the solution entirely on Salesforce. DataIAm for FSC runs inside the customer’s Salesforce org. No additional middleware. No external infrastructure to manage.

    Second, we built the user experience using Salesforce Lightning Design System (SLDS 2) because we believe partner products should feel like Salesforce.

    Finally, we made pricing part of the product design. Affordable pricing wasn’t an afterthought—it was one of the original design goals.

    Our goal was to solve one specific implementation challenge exceptionally well.

    Why did we start with the core banking use case for Financial Services Cloud?

    Because the problem was well understood and highly repeatable.

    Every bank is different, but many of the foundational integration patterns are remarkably similar. That made core banking integration the ideal use case to prove that implementation knowledge can itself become a product.

    FSC is only the beginning. Salesforce Industries includes many industry-specific clouds, and we believe the same philosophy can help accelerate implementations across many of them.

    We believe many enterprise applications can benefit from purpose-built, Salesforce-native integrations that eliminate repetitive implementation work while preserving the flexibility customers expect from the Salesforce platform.

    Looking back, building the software turned out to be the easy part. The real challenge—and ultimately the real product—was capturing years of implementation knowledge and making it reusable for every customer that followed.

    Whether we’re helping a Salesforce Admin import a spreadsheet with DataIAm Fix & Load or helping a bank connect its core banking system to Financial Services Cloud with DataIAm for FSC, our mission remains the same.

    Make Salesforce data effortless.

    To learn more about DataIAm visit: https://dataiam.com

    Zeb Mahmood

    Zeb Mahmood Co-Founder & CEO DataIAm

  • Be different! And win!

    Be different! And win!

    Most founders think they need the perfect résumé, the right connections, or the proven playbook to win.

    But in 1983, a 61-year-old farmer proved that sometimes the unconventional path changes everything.

    The Race No One Expected Him to Finish

    The race was brutal: 544 miles from Sydney to Melbourne. Elite ultramarathon runners—half his age—lined up, trained and sponsored, ready for glory.

    Then came Cliff Young. A 61 years old potato farmer in overalls and gumboots. No coach, no strategy, no special gear. Just years of chasing sheep across thousands of acres… and a belief in himself.

    The crowd laughed when they saw him. He didn’t even look like a runner.

    The Shuffle That Changed Everything

    When the gun fired, Cliff set off with a strange, awkward gait. Reporters called it the “Young Shuffle”. Runners disappeared into the distance while Cliff lagged behind.

    But while the elites followed tradition—running 18 hours, sleeping 6—Cliff kept shuffling. Through the night. Through the pain. Through every mile.

    By not knowing the “rules,” he broke them.

    By not stopping, he won.

    Cliff crossed the finish line 10 hours ahead of the the athlete in the 2nd position. A farmer in gumboots, rewrote the history of ultramarathons.

    What Startups Can Learn from Cliff Young

    1. Credentials don’t decide outcomes– Cliff had no résumé that said “elite athlete”. Founders don’t need one either.
    2. Ignorance can be freedom He didn’t know the “right” way to run a ultramarathon. That ignorance became his edge.
    3. Persistence beats pedigree Endless shuffling outlasted the best-trained runners. Startups win the same way—by refusing to stop.

    Why This Inspires Us at DataIAm

    At DataIAm, we’re building with the same mindset.

    We don’t follow the playbook of traditional data tools—complex, bloated, built only for engineers. Instead, we’re taking a different path: making Salesforce data loading and fixing radically simple, for anyone.

    Just like Cliff’s shuffle, it may look unconventional. But we believe it’s the winning strategy.


    Sometimes, it’s the potato farmer in gumboots who rewrites the rules of the race.

    For startups, that’s the reminder: the path no one expects may be the one that wins.

    👉 What’s your “Young Shuffle”?

    To learn more about DataIAm visit: https://dataiam.com

    Zeb Mahmood

    Zeb Mahmood Co-Founder & CEO DataIAm

  • Product managers don’t control the product — we can only aspire to intervene

    Product managers don’t control the product — we can only aspire to intervene


    I never set out to study architecture engineering. I stumbled into architecture almost by accident. But once I was there, I was hooked.

    It was the perfect intersection of engineering and art. I can still see my professor at the chalkboard sketching a design in seconds, narrating an architectural style as if he were pulling it straight out of thin air.

    Architecture wasn’t just about lines on paper. In materials engineering, I learned how the right choices could balance insulation, sustainability, and aesthetics. In structural engineering, I discovered the art of the possible: Would this design hold? Could it withstand a flood or an earthquake?

    I felt found.

    But life had other plans. I had to switch colleges (that story for another day), and the new one didn’t offer architecture. So, I enrolled in computer engineering instead. Studying programming, data structures, databases, software engineering — the whole enchilada.

    From there, my career journey carried me from writing backend code, to delivering customizations in professional services, and ultimately to product management — my home for the past two decades. I fell in love with the craft of product management, but my fascination with architecture never disappeared; it lingered quietly in the background.

    YES IS MORE

    Recently, while trying to clear my head before diving into my latest project — DataIAm  — I picked up a book by Danish architect Bjarke Ingels, titled YES IS MORE. I thought it would be an escape, something unrelated to work. Turns out, it was the opposite: an architecture book that spoke directly to my product management soul.

    One page stopped me in my tracks:

    “Architecture is never triggered by a single event, never conceived by a single mind, and never shaped by a single hand…. We architects don’t control the city — we can only aspire to intervene.”

    I read it once as an admirer of architecture. Then I read it again as a product manager. And I realized: the same is true of products.

    Slightly reworded, it could have read:

    A product is never triggered by a single event, never conceived by a single mind, and never shaped by a single hand…. We product managers don’t control the product — we can only aspire to intervene.”

    That hit me.

    The Architecture of Products

    In architecture, you balance the technical (Will the structure hold up?) with the artistic (Will people feel inspired, connected, at home here?).

    Product management, it turns out, is no different. It’s half engineering and half art. It’s about building consensus — not by simply creating what everyone already agrees on, but by bridging the gap between what people like, what they want, what they think they need, and what they’ll only realize they love once they have it.

    Over the last two decades, I’ve had the privilege of designing and launching many products. But as I was shaping DataIAm Fix & Load , the philosophy of YES IS MORE gave me a new lens. Had I not read that book, the design and build of DataIAm app and website would have looked very different. What seemed like an “unrelated” book turned out to be deeply related, reinforcing that products — like buildings — are about creating spaces where people belong, thrive, and say: “This is exactly what I didn’t know I needed.”

    YES IS MORE (than architecture)

    Bjarke Ingels titled his book YES IS MORE as a playful response to Mies van der Rohe’s mantra “Less Is More” — a phrase we product managers often find ourselves saying, too.

    But in product management, YES IS MORE isn’t about saying yes to everything. It’s about saying yes to bold ideas — the ones that connect engineering with art, push boundaries while pulling people in.

    That’s why I’ve come to believe:

    Software product managers are just building architects in disguise.

    We may not shape skylines, but we shape the digital spaces where people live parts of their lives. And just like great architecture, the best products don’t just meet needs — they surprise us with a sense of belonging we didn’t know we were missing.


    To learn more about DataIAm visit: https://dataiam.com

    Zeb Mahmood

    Zeb Mahmood Co-Founder & CEO DataIAm

  • Using war jargon at work?

    Using war jargon at work?

    Ever been in a war room trying to come up with a killer go-to-market strategy? Maybe your manager asked for a battle plan while you were still nursing your battle scars from the last product launch. Corporate-speak can get… intense. We’ve all heard (or said) things like:

    • “Let’s nuke the competition!”
    • “We need some serious ammo for this pitch”
    • “She’s a straight shooter”
    • “We’re in the trenches together”

    Sometimes it’s tossed around jokingly; other times, it’s just… reflex. It’s part of that unspoken dialect of business meetings, strategy sessions, and LinkedIn posts. But if you step back for a moment, it’s worth asking: Why does the language of work so often sound like the language of war?

    For Some, War Is Real

    For most of us, thankfully not. But for some—our colleagues, customers, and fellow humans —war isn’t a metaphor. It’s real. And ongoing. They’ve lived it, lost loved ones to it, or carry memories and scars that don’t fade when the quarterly numbers come in.

    So when we casually toss around phrases like “war chest”, “purple heart”,  or  “blitz”, it can hit harder than we intend. Not because we mean harm—but because we forget that language, like anything else, matters.

    Imagine sitting in a QBR meeting while quietly coping with the trauma of real war. Hearing your teammates describe Q2 sales as a “turf battle” might not land the way they think it does.

    We’re Trying to Unlearn

    I’ll be honest—I’ve definitely used this language myself after 2 decades in the corporate world. But over the past several years, I’ve made a conscious effort to unlearn it. Because words matter.

    At the startup I co-founded, DataIAm, we try to keep our language intentional, positive, and—most importantly—human. We don’t believe another vendor has to “lose” for us to “win the battle”. We can all succeed by focusing on what matters: helping customers succeed.

    blog-img

    Suggestions, If We May

    Here are some alternatives to lighten things up without losing your point:

    War-ish JargonNon-War AlternativeFun / Playful Alternative
    War RoomProject RoomCatalyst Room
    Hit the Ground RunningJumpstartLaunch Mode, Turbo Boost
    Battle PlanAction PlanGame Plan
    In the TrenchesHands-OnRolling Up Our Sleeves
    Nuke the CompetitionOutperformBBC: Be Better than the Competition
    Ammo for the PitchTalking PointsMic Drop Material
    Guerrilla MarketingScrappy MarketingLoCoHi Marketing: Low-Cost, High-Impact

    Still cool. Just a bit more… compassionate.

    Let’s Make Work Feel More Human

    Small changes in language can create space for more inclusivity, empathy, and respect. Especially in global, remote-first work cultures—where we don’t always know what our teammates have lived through—it pays to be thoughtful.

    Let’s make our workspaces more inclusive, intentional, and respectful of all the life experiences people carry with them.


    About the Author

    Zeb Mahmood has spent his career unlocking business value by moving, fixing, and loading data—first as an engineer, then as a product leader, and now as a cofounder.

    With 2 decades in product management, 9 years at Salesforce, and hands-on experience in early-stage startups, he’s learned a simple truth: data is the lifeblood of every business. But when it’s messy or trapped in spreadsheets, it can’t drive impact.

    That’s why Zeb cofounded DataIAm — a Fix & Load AI built for Salesforce Admins and data handlers who just want their data to work. No frustration. No failed imports. Just clean, reliable data that loads seamlessly into Salesforce and delivers results.

    Zeb believes great products don’t win on tech alone — they win through empathy. Empathy for users, buyers, partners, and the people building the product every day.

    Zeb Mahmood

    Zeb Mahmood Co-founder CEO DataIAm