Welcome to The Steady Beat, a weekly-ish round-up of hand-picked articles and resources for people who make software products: designers, engineers, product managers, and organizational leaders. This week, we take a look at familiarity vs novelty, the problem with GraphQL, applying product management to anything, and when to micromanage.
The case for design novelty
Familiarity in design is key, allowing users to transfer their experience between similar products and services. However, there are times when designing for novelty is the way forward, such as when differentiation from competition (or incumbents) is the goal, or when exploration is desired. Unconventional layouts, interactions, and animations all can make an experience stand out. But don’t forget the basics - it’s essential to root design decisions in thorough user research and rigorous testing.
The Laws of UX, 4m
Breaking up with GraphQL
While GraphQL was a breath of fresh air compared to untyped JSON REST APIs when it was released, Matt explains why he now finds it burdensome. His main concerns are an increased attack surface, authorization and rate limiting challenges, and performance issues (N+1 problems, coupling of business logic to the transport layer, and complexity of mitigations and testing). So what’s the alternative? Back to the well: OpenAPI 3.0+ compliant JSON REST APIs, which now offer similar benefits without the complexity.
Yes, you’re building a product
Most professionals, regardless of their role, are building something for someone else’s use. This “product” can be a project, program, or process, and its “customers” might be coworkers or external users. However, many non-product teams miss out on valuable opportunities by overlooking a product development mindset – understanding the customer’s needs, iterating on design and experience, and continuously seeking feedback to improve the thing. By treating your work like product development, you can create something truly valuable and effective, rather than just following “best practices” or traditional approaches.
Work Bravely, 8m
Don’t always be the sh!t umbrella
Will Larson, veteran tech leader, discusses common missteps in engineering leadership: avoiding micromanagement at all costs, fixating on perfect metrics, and shielding teams from external pressures. Drawing from his experience at Stripe, Uber, and Carta, Larson advises leaders to engage in the details when necessary, use imperfect metrics to drive learning, and integrate teams into some messy organizational realities. His message: flexibility, context, and continuous adaptation are key to better leadership.
First Round Review, 15m
Steady: Using the Jump Menu
Here’s how you can use the jump menu in Steady to instantly understand who’s working on what in an agile org, no meetings required:
