PJ Ople

Does anyone else remember sitting in class thinking, "Am I ever going to actually use this?" 🤦‍♂️ I still ask myself this weekly when reading blog posts, listening to podcasts, catching up on massive Slack threads, or diving into documentation and feature listings. I don't always use the info, but it feels great when a memory from six months ago suddenly becomes relevant. I always think of that original Jurassic Park Unix scene. This often happens when discussing DevOps and Serverless, where boundaries blur already. Trying to keep all of the AWS documentation in my head while discussing the design of new features and optimizations feels like a superhuman task. What are some things you wish you had remembered when solving an issue or problem? For me, we designed a Lambda function to fail purposefully instead of attempting to recover for efficiency. Unfortunately, the Lambda control plane self-throttles a function once a failure threshold is reached... slowing our processing to a crawl and forcing some quick code changes. 😅 #AWS #lambda #serverless #learninginpublic #hugops

13

1 Comment

The past two years at StarTree, working with the Apache Pinot community, have been fantastic. I’ve been able to get to know some incredibly talented people, and it’s validated my perspective that the advent of event-driven architecture is real and pressing, and even more interesting than I realized. Looking back, I’d never spent that much time focusing on analytics and the huge set of tools and concerns that attend it. It’s a critical ecosystem with a history deeper than digital computing itself, and I anticipate a lot of fruitful work with the Pinot community in the months and years to come. That being said, it’s ironic that my time working with this community has crystallized an important idea I’d been developing since before I joined it. The disruption introduced into our world by the perfect storm of the cloud, microservices, and ubiquitous Kafka has created an entirely new approach to building business software. It’s new, uncharted territory to be explored—and I want to help map out as much of it as possible, together with the hundreds and thousands developers who are doing the work of building applications in this new world. That’s why I’ve decided to transition from StarTree, and return to Confluent as VP of Developer Relations. The most valuable thing we can do as developers is write differentiated code that provides meaningful value to our customers or users. That code sits atop a huge stack of what is, with respect to their businesses, undifferentiated software—various kinds of frameworks and infrastructure components—that solves hard problems that application developers shouldn’t have to spend time on. They shouldn’t build that software, but they need to know how to navigate the terrain and make choices in the space they can trust. The problem is that the event-driven revolution has thrown a somewhat stable stack into relative disarray, so some of us are lured into creating little bits of data infrastructure in that unknown area between our code and Kafka. Those of us who are able to avoid that temptation still aren’t totally clear on what all that terrain looks like, and what infrastructure should even live there. History suggests this could take another five to ten years to stabilize. It will require the input of many communities, vendors, and a world full of developers. In my opinion, Confluent is the company that is best positioned to significantly move the needle on this problem, and that’s why I’m excited to (re)join them. One company can’t do it all, but their vision of the Data Streaming Platform is exactly what I’m talking about here. The opportunity to lead a world-class developer relations team at the company which has pioneered the journey so far, and is building the most comprehensive vision for its next stage, is a tremendous one. I’m delighted to be back, and eager to do my part to help chart our course to the future. It is, as I am wont to say, a wonderful time to be alive.

917

291 Comments

TLDR: 🚀 In 6 months, I've transformed my challenging homebuying experience into Home inSights—an AI-driven app I built to help navigate Portland, ME's challenging market. Like, share and read on to see how you can help. 🏠 Like many of you, I've faced the challenges of today's housing market firsthand. In just one year, we made 10 offers, toured dozens of homes, and combed through hundreds of listings. After repeatedly coming up short, I had a realization — the current tools weren't serving the actual consumers: homebuyers and homeowners. 📈 In Portland, home prices have surged by 85% and mortgage costs have tripled in just five years. We're in the midst of a nationwide crisis marked by limited supply, skyrocketing prices, and escalating borrowing costs. With this increased pressure on consumers, homebuyers need all the help they can get. 🔍 Home inSights is built to empower buyers and homeowners with personalized insights, community discussion, and smart comparison tools. You may be a home owner wanting to better estimate the equity you can roll forward, waiting for the right home to popup within a school district, or a new buyer with constantly changing buying power. Existing apps prioritize lead generation, and maintain this information asymmetry. There is a better way. 🌅 This version of Home inSights is only the beginning, currently focused on the Portland market. I’m racing to keep building this, but I want to begin including you all. Here’s my backstory on why I’m embarking on this journey: 💼 My career began in the aftermath of the last housing crisis. I worked on mortgage-backed securities lawsuits worth billions, reviewing tens of thousands of mortgages. The countless stories of hardship have stayed with me, fueling a deep-seated desire to make a difference. 👔 As a CFA charter holder, I love markets and valuations and feel driven to help make the market better by empowering consumers through information and tooling. 🥒 Later, I grew my family's pickle company to $3M revenue, gained hands-on business management experience, learned to listen to customers, and how to grow and lead teams when the future is unknown. 📱 Most recently, at Appex, I managed dozens of mobile apps with hundreds of thousands of consumers, worked with many founders, and learned how to build a mobile business. 💡🤖 But I wasn't a coder. Determined to create a solution, I turned to AI. In a few months, I launched not one, but two apps. These unique keystone experiences laid the foundation for what has become Home inSights. If you have read this far, thank you thank you thank you. 🫵 Any help is appreciated: 👍 1. Like, share, comment and/or tag someone on this post 🫶 2. Follow my progress on Instagram: @Buildwithphil.ai 📲 3. Download Home Insights on iOS, subscribe to support ongoing development, and share feedback https://lnkd.in/eQQc8tm9

58

8 Comments

You know there's some momentum happening if Marty Cagan decides to write about a product topic you've been at work trying to enable for years. Love to see it, and BIG shout out to Stacey Langer for providing her expertise in this article! 🧘‍♀️ Here are a few other pros that came to mind for the product model: 1. The government product model makes product (public) value and risk management possible. Product risks—such as value, desirability, viability, and feasibility—are not risks that traditional project management models can effectively manage. Government agencies interact with the public through the services they offer, but government digital experiences are not always inherently valuable. It’s what these digital services do for users that create individual and public value. Building tech alone ≠ value. 2. Evidence-driven decision-making uses discovery, iterative delivery, and testing with actual end users, where you continuously learn. This enables many things, mainly building with your users while validating the solution direction. It can also enable an incremental funding option specifically for products/services (traditionally called ‘projects’) that are especially complex, high priority, and/or contain many unknowns. 3. Driving technology from a place of vision and strategy measured in outcomes that can align and even influence policy changes. 🤸‍♀️ Some realities in trying to adopt a product model in gov: 1. The word ‘product’ often can be confusing, especially when it doesn’t fully represent what is being built and managed. A lot, if not most, of the technology work happening in government often involves solving service design challenges. So, in gov products, you focus on solving for the end-to-end experience, which can mean processes and non-tech things. 2. Conway’s Law and government systems replicate the organizational structures in agencies, which are often siloed and isolated. This is often represented as 'legacy tech.' Much of the work in 'product' in government is modernizing legacy systems, which requires the same principles as the product model but often a different emphasis on its varied approaches. Not all products or digital services start from the same place; many are not greenfield. 3. Traditional ATO structures can stop the product operating model in its tracks. To overcome this, it is important to integrate the ATO into the product model, utilizing a ‘continuous ATO’ operating model. But see point 2 above. At the end of the day, the product model isn’t a process you learn to implement and then just implement. It’s not just ‘Agile’ or Scrum or DevOps. Those methods can (or sometimes can’t) enable the product model. It's a mentality and discipline for continuously using new inputs to deliver value throughout a product's LIFE. It's a cultural change as much as an operating change, and there is no 'single way' to do it. However, operating from product thinking principles can help us start from the right place.

23

3 Comments