Jill Wetzler

Excited to share a recent conversation I had with Ankit Jain, a community leader in the Developer Experience space and Co-founder/CEO of Aviator, where we dug into what it's like being a PM in the DevEx space. We covered some key themes: 🛠️ Why internal developers deserve the same care and empathy as external customers 🧠 How core product principles—like understanding the problem deeply—still drive success, even in highly technical spaces 📊 What meaningful impact looks like in DevEx If you're curious about building for builders or just want to hear how DevEx works behind the scenes at scale, give it a listen: 🎧 https://lnkd.in/gUpm4-Np #DevEx #ProductManagement #DeveloperExperience #podcast

62

3 Comments

The circles of Control, Influence, and Concern Early in our careers, we’re often told to “own the outcome.” As we grow, that ownership broadens beyond code or systems — it extends into people, mechanisms, and culture. Stephen Covey’s Circles of Control, Influence, and Concern provide a simple but powerful framework for reflection — one that we all live through daily. Circle of Control This is what you can directly act upon — your code, design quality, and decisions. It’s where you move fast because you don’t need permission to do what’s right for the system. For me, this means writing tenets, defining metrics, reviewing designs, and raising the bar on engineering standards. Circle of Influence This is where leadership without authority matters. You can’t force a change here — but you can shape it. Influence is built through clarity, trust, and data. When you help another org simplify a design, mentor an SDE into a stronger reviewer, or align leaders on shutting down a misaligned project — you’re operating here. Your success depends not on hierarchy, but on how consistently you demonstrate judgment, objectivity, and customer obsession. Circle of Concern This includes everything you care about but can’t control — like organizational priorities, macro-level business shifts, or leadership changes. The key here is emotional discipline. Those who spend energy worrying about concerns they can’t act on end up drained. Those who channel that energy back into influence — writing a clear doc, proposing a mechanism, or building alignment — create impact. Success isn’t about controlling everything; it’s about knowing where to invest your judgment, where to build trust, and where to let go. How do you decide which circle your current challenge belongs to?

34

More than $4 trillion in equity compensation (RSU, ISO, ESPP etc) remains unmanaged for employees. Founded by veterans in this field, Grantd helps financial advisors transform this complex, often-overlooked benefit into actionable tax-informed strategies for clients and new business opportunities for advisories. We’re excited to see our strategic partners share this vision and place their trust in the team.

8

CPTO Revolution: Why SaaS Companies Are Merging Product and Tech Leadership I’ve lived the pain of siloed leadership and the inefficiencies it creates many times. And I’ve also seen how tightly integrated product and tech can transform not just delivery, but outcomes. Traditional org charts are no longer keeping up. The most competitive SaaS companies aren’t hiring separate CTOs and CPOs anymore - they’re bringing both roles under one roof with CPTOs. This isn’t about headcount optimization. It’s about reducing friction and moving faster in a world where complexity is climbing and customer expectations evolve by the week. Here’s the core issue: when product and engineering leadership are separate, you’re always playing a game of telephone. Product defines what’s needed. Engineering estimates and negotiates. Product pushes. Engineering pushes back. Handoffs everywhere. Every step is a delay. A CPTO owns the entire journey - from insight to shipped product. One person accountable. One vision. One continuous flow. And it works. Companies running this model are seeing up to 40% faster go-to-market. Less tech debt. Clearer priorities. Higher team velocity. What Actually Changes 1. Aligned Metrics You stop optimizing for isolated outcomes. Product isn’t chasing adoption while engineering shields uptime. Both roll into shared business goals. 2. AI Gets Strategic With unified leadership, AI isn’t a bolt-on. It becomes core to how you design, build, and validate products - through data, feedback loops, and automation. 3. Developer Experience Matters Platform engineering gets the attention it deserves. Internal tools align with product delivery, and suddenly teams aren’t waiting - they’re shipping. UX maturity, platform architecture, technical scalability - all of it becomes a single continuum. You’re not just improving “process”; you’re aligning every decision to what users need and what’s feasible to build. The CPTO Skillset This isn’t a hybrid role - it’s an integrated one. You need the technical depth to guide architecture and the product judgment to say no to overengineering. You talk to engineers about latency and reliability, and to the board about market traction and differentiation. As AI accelerates software development, what matters is orchestration—of systems, teams, and strategy. You need to see the whole board. Cloud infra spend is growing ~10% yearly, mostly due to AI. That spend needs direction. CPTOs are the ones who can match innovation speed with platform efficiency. Companies clinging to the old CTO/CPO split are playing a slower game. Integration is no longer optional - it’s a competitive advantage. So—what’s keeping your org from making the leap?

15

Hardcore cultures measure hours. Progressive cultures measure outcomes. Betterworks CEO Doug Dennerline warns that RTO mandates and “996-style” schedules risk pushing top talent away. Instead, continuous performance models keep people engaged and businesses growing. Outcomes > hours. https://gag.gl/Wgtz5C

3

Watching Super Pumped (Episode 1) sparked a few leadership reflections. 1. Great leaders operate with a sense of urgency - not panic, but momentum. In fast-moving tech environments, speed combined with clarity often beats perfection. 2. Trust isn’t granted with a title; it’s earned through consistency, decision-making, and how you show up under pressure. Early resistance is not rejection; it’s evaluation. 3. Uncertainty is constant in tech - scaling, outages, pivots, competition. Leaders don’t freeze. They reframe the problem, think differently, and navigate forward. There is almost always a path out. 4. Sometimes you’re the only one who believes. That lonely conviction often separates leaders from the rest. If everyone already agrees, leadership isn’t required yet. 5. A thin line between brave and reckless There’s a narrow gap between a bold, visionary decision and one that fails instinctively. Outcomes determine the label in hindsight, and that’s okay. No leader is perfect. 6. Decision beats no decision. Inaction is often the most expensive choice. Standing in the middle of a square with four choices, making a decision to step in one direction reduces the unknowns from four to three - decisions create clarity; hesitation creates none. 7. Leadership isn’t about being right all the time. It’s about moving forward when clarity is incomplete.

2

When I was working in online video streaming, we were told we couldn't do CD because TV apps had to be certified by manufacturers. Yet we did CD. It helped us build enough trust so that some manufacturers allowed us to release most changes without certification, and others fast-tracked our certification process. When I was working on internal enterprise software, we were told we couldn't do CD because releases had to be planned and manually tested, deadlines respected, and users trained. Yet again, we did CD. Plans became high-level and abstract as iterative execution took over. Automated acceptance tests and feature flags allowed our QA testers to become our first users in production, rather than gatekeepers for releases. Training was built into the frontend applications. It may be the toughest challenge yet, but I'm determined to make it work in a business SaaS startup, where client demands and approvals are everything. The excuses are plentiful, but I have yet to see a domain where CD has failed to deliver results. After all, some of the most famous CD success stories are about printer firmware and an MMO game. Are you sure the software you are working on is more exotic than that?

19

The customer is not always right, but they’re never wrong. That tension is at the heart of product work. We’re taught to listen. Talk to users. Run discovery. Prioritize outcomes. That’s the JTBD, customer-informed, value-driven approach. It’s where good product work begins. But then come the quotes from Jobs, Ford, and others. "If I had asked people, they would have asked for faster horses." "People don’t know what they want until you show it to them." Suddenly, we are told to stop listening and start leading. Invent the future. Anticipate what no one is asking for. It creates a real pull between two mindsets: 🟣 Listen first vs. lead first 🟣 Servant to the customer vs. shaper of the market 🟣 Validation vs. invention The truth is, most great product work sits in the middle. The best PMs are not order takers or solo geniuses. They are translators. They take what users say, find what they actually need, and build something that creates real progress. They listen hard but don’t treat every request as gospel. They lead with a point of view but stay grounded in real-world problems. Being customer-led doesn’t mean building everything customers ask for. Being visionary doesn’t mean ignoring the people you are here to serve. It is not either-or. It is a tension. And learning to work inside that tension is the real job. Curious how others think about this. Where do you follow feedback, and where do you trust your gut? #productmanagement #JTBD #productstrategy #leadership #innovation

15

2 Comments

Think of CIEM integrations like a universal translator for your cloud: because AWS, Azure, and GCP definitely aren't speaking the same language when it comes to permissions. 🌍🗣️ #CloudSecurity #IdentityAccessManagement #CIEM #ZeroTrust #CyberSecurity #MultiCloud #DevSecOps

1

I’ve been writing a series of posts on the design principles behind Looping, a product I’m building to help teams run and evolve software over time. These principles shape the architecture underneath and have helped me prioritize clarity, composability, and long-term maintainability from the start. The latest post in the series is about Composable Services. In Looping, every service follows the same interface: it takes a hash of input and returns either Success() or Failure(). That consistency makes services easy to test, reuse, and chain together without resorting to sprawling conditionals or unpredictable side effects. The post walks through the structure, shows real examples, and touches on how it tracks source chains for observability and event logging. https://lnkd.in/ePkn-pF6 #ruby #rails #softwarearchitecture #buildinpublic

7

2 Comments