To my understanding, CI/CD at its core just refers to the practice of frequently merging in code and releasing new builds. Why, then, are tools like github actions and other automated testing/building tools strongly associated with CI/CD? Isn’t this automated tooling something we’d want even with less frequent integration and deployment practices?

Are paid AI courses actually worth it, or can we learn everything through free resources? For someone aiming to become an AI Engineer, what extra value should a paid course provide to justify the cost? Would love to hear from people who have tried both, especially regarding projects, mentorship and job opportunities.

https://news.mit.edu/2026/margaret-hamilton-computing-pioneer-dies-1007

Mad respect to these brilliant people who paved the way for many of us.

Hi folks, Stjepan from Manning here. The mods gave us permission to share this.

A feature can be well-designed, tested, and delivered on schedule, and still leave the user’s problem untouched. What interests me is how engineers recognize that before the team has spent three months building it.

Take a request for a dashboard. That’s already a proposed solution. The underlying problem might be “I can’t tell which jobs have failed” or “I spend Friday afternoon assembling a report.” Those are different problems, with potentially very different engineering costs.

Asking which one we’re solving sounds straightforward. Doing it when the roadmap is committed, and everyone wants an estimate, is harder.

That’s why I wanted to bring Jon Bennallick’s Product Thinking for Engineers here. It’s now in Manning’s Early Access Program (MEAP), and it focuses on the judgment engineers bring to decisions about what gets built.

The part I find especially relevant is pushing back with evidence. “This feature seems pointless” doesn’t give a team much to work with. “What evidence would tell us this is worth building, and could we test that before committing to the full implementation?” opens a more useful conversation.

Of course, engineers don’t always have access to users or authority over priorities. Better questions won’t magically fix that. But making assumptions and costs explicit can help a team distinguish a technical disagreement from a disagreement about what users actually need.

The book covers turning user feedback into actionable decisions, spotting low-value work early, and discussing cost and commercial value. Jon uses actual projects from agencies, scale-ups, and smaller businesses, including his own mistakes. There’s no code or framework tutorial; the focus is contributing to product decisions without having to become a product manager.

Book and available MEAP chapters:
https://www.manning.com/books/product-thinking-for-engineers

MEAP means you can read chapters as they’re written, with the finished ebook included when it’s ready.

We’re giving away 5 ebook copies to the 5 people whose comments contribute most thoughtfully to this discussion. We’ll choose based on the substance of the contribution, not upvotes or whether you agree with the book’s premise. A useful counterexample absolutely counts.

Manning is also offering the community 50% off the book with code MLBENNALLICK50RE.

Here’s the question I’d love to hear your experience with: when did your team build exactly what was asked for, but miss the underlying need? What would have helped you catch it earlier—and did you actually have room to challenge the request?

A thoughtful account of what didn’t work is just as welcome as a success story.

Thanks for having us.

Cheers,

Stjepan