"Set expectations appropriately" sounds cliché, maybe because those of us who have been in the trenches of product management know that we have to do it and also know how difficult it really is to "set expectations appropriately." Organizations are human, after all, and there does need to be a certain level of excitement (or promise of success) to get the buy in and support needed to build a game, a software feature, or a physical product. However, and those of us that have been in this for years know by instinct (and probably by scars), that it's important to manage expectations of our leadership, of our teams, and of our audience.

Building features and knocking them out of the park (by whatever appropriate metric you have determined) on the first try is (extremely) hard - and is an unrealistic expectation. The few situations where you might see this happen are those environments that prioritize user research, delve deep into the problem space, build mock ups, do low fidelity tests, and even then, it's not guaranteed. (And I would argue that if you're building prototypes, testing them with your audience, and iterating on that feedback, it's not really a one-shot, is it?). Even if you do go down the route of extensive research, you still need to manage expectations of leadership and keep them abreast of the successes, challenges, and what is left still to discover of the product team's efforts.

And you're still just in the development phase in the example above. I've seen a lot of people fret over "getting it right" the first time, feeling that the reception at launch or that the v1.0 of the game is what defines success. That, if we miss that first impression, we're doomed. That misalignment, between what is reality and what is in everyone's heads - including your own - is why managing expectations are important. While this might sound like well trodden ground for most, the drive to hit out of the park in one swing happens more than we'd like to admit.

Now, I'm not saying that Product Managers, or Producers, in their stead, can control the minds of others around them, but we do have an outsized impact on how people perceive the effort that the organization is undertaking and what the results can be. We can create an environment where there's a shared understanding of what success might look like and set the guardrails around that path. Building games or software is inherently a creative process - part of what we should be doing is reducing the uncertainty around what we're doing.

So, what does that look like? We create an environment that fosters flexibility, experimentation, and learning. We make sure that the vision is at the center of everything we do and that the constraints are well understood. If we have a short runway, then we need to more modest about our scope. We need to be able to iterate many times to get that experience locked down or the solve the user's problem. We need to be able to validate that with actual players or users.

Help the team focus on what's important and what's impactful of what they're working on. Tie those efforts to what the org should expect to learn. Are we delighting our players by doing X? Is the user's Y problem being solved? Are we getting in the way of either?

And for that, you need to set leadership's expectations. That to be successful (or to increase your chances at being successful), you need to experiment and iterate with a live audience. That we can't keep everything under wraps and expect to hit it out of the park on the first try. And then deliver on that. Involve your audience: playtest, demo, have conversation, probe, and question them. Keep leadership - and the greater org - updated on the results of those conversations.

You goal here is to get many chances at getting it right. You should know that you're not going to get it right with v1.0. So help the organization get set up to learn that and set expectations accordingly. Both successes - with a small "s" - and failures can teach a lot, but the organization has to be ready to learn from those experiences.

/r