Menu

How Brasília’s urban design affects citizen behavior during political violence

My friend Allan sent me an article about the city of Brasília, and how its architecture affected the recent insurrection (Ryan wrote the best overview about what happened that I’ve seen). I have long been fascinated with Brasília, every since I researched it for a product management article called Usable yet Useless: Why Every Business Needs Product Discovery:

A “shiny citadel” from far away, as The Guardian once wrote, up close Brasília has “degraded into a violent, crime-ridden sprawl of cacophonous traffic jams. The real Brazil has spilled into its utopian vision.”

This problem echoes across today’s web landscape as well, where the needs of ordinary users spill constantly into designers’ utopian vision.

So I read In Brasília, Modernist Architecture Met Political Violence with great interest:

Brasília’s so-called Monumental Axis, or Eixo Monumental, isn’t a walkable touristic path dotted by free museums. Instead, it is an otherworldly landscape of red earth, open grass and enormous roadways, an anti-pedestrian landscape best viewed from the air. So vast are its voids that the sheer scale of the space may have helped temper the energies of the crowds.

The city’s design had specific consequences for the political unrest:

More than 60 years later, Brasília’s real-world shortcomings are well known: Its population far outgrew what its designers imagined, with most residents living in satellite developments that sprawl far from Costa’s planned central district. Many politicians commute via plane, making the city more a symbolic site than a place where one finds gatherings of politicians. President Lula was not in Brasília at the time of the riot, nor were legislators of Brazil’s National Congress, which is in recess: The protesters attacked mostly empty buildings.

This is a really interesting look at how urban design affects the behavior of citizens.

Letting books talk to each other

I love this bit from Austin Kleon’s Letting books talk to each other:

If you read books on different topics and different genres and different formats at the same time, your brain can’t help but find weird connections between them.

This is one of my favorite things—not just with books, but with articles too. It’s such a good feeling when your brain makes those connections. I’ll add that I think this is what makes blogs like Kottke so effective and compelling. When you are able to find and share the connections between things, you have something special going on.

Things they didn’t teach you about Software Engineering

Good post by Vadim Kravcenko on Things they didn’t teach you about Software Engineering:

Although it may sound surprising, the primary focus of a software engineer’s job is not writing code but rather creating value through the use of software that was written. […] Elegant code, best practices, smart solutions, design patterns — these are done for the sake of your fellow software engineers who will work on the codebase after you rather than helping you fulfill the purpose of bringing value.

And speaking of meetings:

It’s all interconnected, and the meetings are where the information is shared. As a software engineer, you are responsible for some part of this information sharing, so it would be irresponsible to hinder it. You might not like it, but the information must be shared for the system to remain efficient.

When meetings are outlawed, only outlaws will hold meetings

Here is a good articulation of why I wasn’t as enthusiastic about the Shopify meeting cancelation thing as most everyone else. Something felt… off? Here’s the Raw Signal team in When meetings are outlawed, only outlaws will hold meetings:

But the long-term fix for bad meetings isn’t no meetings, it’s competence. If you run a bad meeting, you need to fix the meeting or cancel it. But if you run a company full of bad meetings that need annual reboots, you need to fix your management team. Because while collaboration, alignment, decision making, and unit cohesion can all happen outside of meetings, well-run meetings are a very useful and effective place to accomplish those things. Taking that tool out of your management toolbox might be prudent if you don’t trust your managers to use it without hurting themselves or others. But it would be better if they were competent.

Also this:

Running an effective meeting means being opinionated about what it is and isn’t for, and fierce about not wasting the time of your invitees.

→ Context: Shopify CEO Tobi Lutke Tells Employees To Just Say No to Meetings.

Quote: How to spend your first 30 days in a new senior-level role

No matter how well-intentioned you are, enacting change within your first 30 days could jeopardize your trust and standing. So if you feel any of those reasons eating at you, please pause. Spend these first 30 days sitting in on team meetings and talking to everybody on the team.

— Lara Hogan, How to spend your first 30 days in a new senior-level role

Slack vs. Microsoft Teams, and the forces at work when choosing a product

John Gruber has some strong B2B product management analysis in Was Salesforce’s Acquisition of Slack a Bust?

I think Slack is to Teams today where Mac OS was to Windows in the mid-1990s: better designed, for sure, but not in a way that makes a difference to the corporate IT decision makers who are making the call on which platform to use.

The key is not merely to be better, on some vectors. The key is to be better on the vectors that people with purchasing power care about. Missing this has been the death knell for many good products.

To use Jobs-to-be-Done language, there are strong forces at work when choosing a product. If the progress-making forces (“Slack is better designed!”) are not stronger than the progress-hindering forces (“Well we already use Microsoft, so we might as well stick with Teams”), people/companies simply won’t switch.

How to make the move away from “feature factory” successful

Itamar Gilad recently published a good post on Feature Factories vs. Value Generators. It starts off with some basic definitions that should be familiar to most readers, but the second half expands on the responsibilities product orgs have to ensure a successful transition away from feature factories. We can’t just sit back and hope the rest of the organization goes along—there’s a very important organizational change element here:

The product org needs to stop viewing itself as a production unit (you’d be surprised how many do). Our job is no longer just to work heads-down developing features per a spec. The product org needs to produce traction towards the goals, and this traction needs to be communicated clearly to the rest of the company (which helps in creating trust). Testing and evidence play a major role.

This bit about what to measure also stood out to me:

I see a lot of OKRs about boosting efficiency and improving productivity. Many CTOs see having developers work at 100% capacity as the prime goal and push their teams to deliver more story points per sprint. While there’s nothing wrong with any of these per se, they are at best second-order optimizations, and at worst major waste generators. The better optimization is pursuing a higher ratio of positive-value launches. If you embrace this goal, a lot of things that you do today will no longer make sense. It’s a long journey, but with persistence and hard work you’ll be able to put the antiquated feature factory model to rest.

The goal for product teams is not “stop being a feature factory,” it’s “provide more value to customers and the business.” Moving away from “the build trap” is just one of many tactics for making that goal a reality.

Tony Fadell on the role, responsibilities, and importance of product management

I recently finished Nest creator Tony Fadell’s book Build: An Unorthodox Guide to Making Things Worth Making (I highly recommend it). I wanted to spend a few moments reflecting on the chapter on product management because it is just so good. I haven’t read something that made me feel this inspired about the importance of what we do in a long time.

First, it’s always fascinating to me how different people define this undefinable role. Here’s what he says:

A product manager’s responsibility is to figure out what the product should do and then create the spec (the description of how it will work) as well as the messaging (the facts you want customers to understand). Then they work with almost every part of the business (engineering, design, customer support, finance, sales, marketing, etc.) to get the product spec’d, built, and brought to market. They ensure that it stays true to its original intent and doesn’t get watered down along the way. But, most importantly, product managers are the voice of the customer. They keep every team in check to make sure they don’t lose sight of the ultimate goal—happy, satisfied customers.

One definition is never enough, though. Every product management book has a few “oh, but also…” sections, and this one is no different:

Product managers look for places where the customer is unhappy. They unravel issues as they go, discovering the root of the problem and working with the team to solve it. They do whatever is necessary to move projects forward—that could be taking notes in meetings or triaging bugs or summarizing customer feedback or organizing team docs or sitting down with designers and sketching something out or meeting with engineering and digging into the code. It’s different for every product.

It’s interesting to read his perspective on product management vs. product marketing (especially since I am also currently reading Martina Lauchengco’s SVPG book Loved: How to Rethink Marketing for Tech Products, which has a decidedly different view on this role):

Most tech companies break out product management and product marketing into two separate roles: Product management defines the product and gets it built. Product marketing writes the messaging—the facts you want to communicate to customers—and gets the product sold. But from my experience that’s a grievous mistake. Those are, and should always be, one job. There should be no separation between what the product will be and how it will be explained—the story has to be utterly cohesive from the beginning.

But my favorite parts of the chapter are the ones that made me feel. There is so much content out there about just how hard the job of product management is, and so little about what an exciting and special role it is. Tony gets to the heart of what makes this work worth doing:

Sometimes they’ll have the final opinion, sometimes they’ll have to say “no,” sometimes they’ll have to direct from the front. But that should be rare. Mostly they empower the team. They help everyone understand the context of what the customer needs, then work together to make the right choices. If a product manager is making all the decisions, then they are not a good product manager.

And:

So the product manager has to be a master negotiator and communicator. They have to influence people without managing them. They have to ask questions and listen and use their superpower—empathy for the customer, empathy for the team—to build bridges and mend road maps. They have to escalate if someone needs to play bad cop, but know they can’t play that card too often. They have to know what to fight for and which battles should be saved for another day. They have to pop up in meetings all over the company where teams are representing their own interests—their schedules, their needs, their issues—and stand alone, advocating for the customer.

He’s right about how difficult the role is to hire for, though:

This person is a needle in a haystack. An almost impossible combination of structured thinker and visionary leader, with incredible passion but also firm follow-through, who’s a vibrant people person but fascinated by technology, an incredible communicator who can work with engineering and think through marketing and not forget the business model, the economics, profitability, PR. They have to be pushy but with a smile, to know when to hold fast and when to let one slide. They’re incredibly rare. Incredibly precious. And they can and will help your business go exactly where it needs to go.

Yes, I know—I just quoted someone who called us “precious,” which is a little obnoxious. But I spend enough time hand-wringing about how we shouldn’t consider ourselves so special (see, for example, The dangerous rise of “crazy-busy” product managers) that I’m going to give myself a freebie here.

Anyway, you should read the book. I have some issues with the parts that lean heavily into hustle culture, but if you ignore those bits it is really fantastic. The ending made me tear up a little bit…

In the end, there are two things that matter: products and people. What you build and who you build it with. The things you make—the ideas you chase and the ideas that chase you—will ultimately define your career. And the people you chase them with may define your life.

More

  1. 1
  2. ...
  3. 31
  4. 32
  5. 33
  6. 34
  7. 35
  8. ...
  9. 201