James Gill has a good overview of How bad features are born:

Most importantly, does this feature deserve to exist? Why are you working on it?

If you’re embarking on a new feature primarily because you’ve seen a competitor release something similar, then you probably haven’t thoroughly considered or even identified the problem you’re trying to solve. If you’re jumping into a new feature because it seems like “it wouldn’t be too hard to do” that’s great, but does it actually deserve to be built right now?

The biggest danger I see is this “it’s easy to implement” argument. A feature might be easy to implement, but that doesn’t make it “cheap”. The problem with implementing even easy features is that they’ll most likely remain in the product forever. That creates the potential for lots of (expensive) maintenance and support.

Also see How Much Does A New Feature Cost?

Joe Tullio has some good tips for remote teams in Distributed UX teams: Early lessons learned. This part, in particular, is something I think many teams ignore because it can feel like busywork:

At Google, we have an internal “snippets” tool for posting regular updates on our work, typically at a weekly cadence. Snippets serve to share the latest mock versions, research reports, study plans, hiring updates, and anything else that feels noteworthy.

To be fair, snippets are a diligence task; I’ve been on teams where these updates were neglected for months at a time. However, my far-flung teammates have been instrumental in encouraging the rest of us to share updates, as they benefit greatly from seeing them. We’ve come up with several ways of reminding ourselves to do them, through calendar appointments, shared compilations, and as a last resort, the tried-and-true email nag.

I’ve written about a similar approach we follow in Useful daily standup meetings for remote teams, and I stand by it. The benefits far outweighs the “cost” of spending a few minutes thinking about your day and updating your team about what you’re working on.

Des Traynor shines a light on the unglamorous side of the PM role in Q&A: What does a product manager do?

If you look at how actual product managers work in any company there’s a lot more nitty gritty work. There’s a lot of spreadsheets, wireframes. Google Docs, emails, and oh-so-many Slack channels. And they all exist to research, collaborate, dictate, and document consensus on a direction the product is going. But I think if the role was titled “Direction and Consensus Manager” you might not get as many applicants.

Chris Jones posted a really solid overview of The Product Designer Role that’s very much worth your time:

Your next task is to define the product design role within your company. This is an important one to get right. You don’t want to simply recreate an internal version of the agency model. The way that products are created has changed dramatically in recent years and new models for design are a critical part of this.

He goes over what he believes are the 5 core responsibilities of the role:

1. Product Orientation
2. Holistic Experience Design
3. Prototyping
4. User Testing
5. Interaction and Visual Design

I can’t help but feel like this is a role we’ll start to see merge with Product Management before long.

Andy Budd asks, Are we moving towards a post-Agile age?

Perhaps we’re moving towards a post-Agile world? A world that is informed by the spirit of Agile, but has much more flexibility and nuance built in.

This post-Agile world draws upon the best elements of Agile, while ditching the dogma. It also draws upon the best elements of Design Thinking and even — God forbid — the dreaded Waterfall process.

People working in a post-Agile way don’t care which canon an idea comes from, as long as it works. The post-Agile practitioner cherrypicks from the best tools available, rather than sticking with a rigid framework. Post-Agile is less of a philosophy and more of a toolkit that has been built up over years of practice.

This is certainly true for how our team works as well. We took the parts we like about Agile (like autonomous teams, flexible roadmaps, daily standups, small pieces of work), left out the parts we don’t like (like rigid sprints, long backlog grooming meetings), and then mixed in some spicy goodness from other methodologies (like deploying whenever a feature is ready). I’m sure strict Agile works for some teams — particularly in large organizations — but this approach works much better for us. It speeds us up and makes us all much happier human beings.

Giff Constable writes about The difference between design and product management and makes this good point about the nature of the PM role:

A big difference is where they spend their time. You’ll hear me call design and engineering “deep dive” roles, while PM is a multi-tasking role, which is why it is relatively easier for PMs to assume more of a leadership role. Even though we work in very collaborative ways (“rough draft culture”) at Axial, both design and engineering require getting into a “flow state” on a problem. Design takes a lot of iteration and trial and error to get something right. PMs, on the other hand, are bouncing around a million tasks, from clarifying a user story, to managing communication inside and outside the organization, to doing whatever it takes to un-bottleneck the team, to all the things listed above.

This is one of the things that makes Product Management such a challenging role. It’s not just about switching tasks, it’s about developing the ability to switch focus really quickly as well. There is no time to meander from one task to the next. Once you switch to the next thing you have to be in it right away.

Laurent-Pierre Baculard makes some great points in WhatsApp Grew to One Billion Users by Focusing on Product, Not Technology:

Examples such as WhatsApp demonstrate that real-world innovation, in many ways, looks like an assembly line. At one end is a customer pain point or a potential new market. At the other is a product or service that solves the problem or addresses the market in a way nobody has thought of before. In between, people sit down and force themselves to examine the problem from a variety of fresh angles. Sometimes they tap the lab and bring a radical new technology to bear. But much more often they reach for pieces of technology that already exist and assemble them with new (or old) capabilities to produce a solution that turns the pain point into a delighted customer. Think of it as high concept meets whatever is lying around — an unconventional combination.

The problem comes when we reach for technologies that seem “cool” but can’t actually be linked to any real customer problem.

Yes, after a long break I’m giving the blog another shot. Let’s see how it goes…

I enjoyed answering some questions about prototyping and Product Management in startups from the nice folks at Justinmind recently. Among other things I got an opportunity to share my thoughts about a particular phrase we hear a lot about Product Managers, one that I think is quite dangerous for our profession…

What kind of challenges and opportunities face Product Managers in a software development context?

I think the Product Management role is still incredibly misunderstood (and misused). I’ve never liked the “We’re like mini-CEOs of the Product” thing you often hear. Any metaphor you come up with that implies a hierarchy (such as air traffic controller, shepherd) gives Product Managers an incorrect view of themselves as The Boss™, and serves only to alienate teams.

We might be the final decider on some issues, but it’s not because we’re “above” the team. It’s because our jobs are to know about user needs, business goals, technical needs, and how all of it comes together in a successful product. Our jobs are to listen to our teams in their various roles and make sure that everyone knows what they need to know. And then our jobs are to walk with the team in a direction that everyone understands and agrees on. It’s not “here are your requirements, see you on the other side of design!” We still see way too much of that in the industry.

Until we change that perception, which will require a change in attitude from us as product managers, we’ll continue to be viewed as obstructionists in many companies. Maybe the best metaphor to use is that we’re servants. Servants to our customers, our teams, and the product. That’s the opportunity we have to bring value.

You can read the full interview here.

I just published a big post on our company blog about how we came up with our priorities and roadmap for Postmark for the next few months. From the intro to How we built a product vision and roadmap:

So, armed with some whiteboard markers, a mountain of sticky notes, and one very enthusiastic team, we set off to plan out the next few months of our product. In this post I’d like to give an overview of what we did, why we did it, and how it’s going to help us (and our Postmark customers!) in the coming months.

This one took a while to write and edit, and there’s some nice illustrations as well as downloadable templates, so take a look!