Building Beyond Fast and Slow

As product managers, we’ve seen and used our fair share of various Agile frameworks such Scrum, Kanban, XP, and many others. In fact, we’re probably currently using one of those frameworks to build our products. For the last part of our series on the Fundamentals of Product Management, we’ve brought in Ian Pestelos to talk at the Zalora office last March 20th about how agile can be used in product management. Ian is an experienced agile coach, an active organizer of the AgilePH community, and has several years of experience working in an agile environment.

WTF is Agile?

Ian starts off the talk by sharing some textbook definitions of Agile and asking whether Agile is a framework, a culture, or if it had something to do with a fast development style. He then shares the story of a team he has worked with in the past who were able to build a product in an Agile manner, but ultimately failed to deliver business value. Ian highlights that while you could build products in an Agile manner, be it in terms of the development framework, your company culture, the speed of delivery, or your choice of Agile framework, it all doesn’t matter if you don’t achieve your expected outcome. He summarizes that being agile is just a starting point — the goal is not to have daily standups or sprints — these are only practices that help you build a better product for your user.

“Agile is not the goal, it is (a) means to an end”

Agile as a Learning Framework

So how do you build a better product for the user? Ian shares that Agile is a learning framework, and not just a software delivery framework. Instead of just looking at the sprints as releasing a potentially shippable product, you can look at the iterations as experiments. In this context, building in an Agile manner is necessary, but not sufficient. Yes, you need to move fast as you constantly create features and release those features in iterations, but more than that, you also need to learn more about the user as you experiment with them and the features you’re releasing. Ian then gives some concrete tips on how to use Agile as a learning framework.

1. Overcome Template-Zombying — Too often we get caught up in following the rituals of our chosen Agile framework, that we fail to realize the underlying intent of those templates. User stories are probably the most common example of this. As we attempt to follow the “As a _____, I want to ____, so that _____” template, we often get too caught up in following the template that it defeats the original purpose of communicating effectively.
2. Manage the System — Instead of expecting people to just give feedback on their own, you need to create an environment where people feel that it is safe to talk. Having psychological safety in the work environment helps create effective teams. As managers, if we want to create a safe space while still maintaining outcomes, we have to grow our own soft skills such that we can facilitate conversations rather than command.
3. Forest for the trees — Focus ruthlessly on the outcome. Specific activities like having retrospectives would not matter as much if the outcome wasn’t being delivered. Further, focusing on the outcomes allows us to workaround current existing constraints that may otherwise trap us.
4. Mind your gaps — You don’t know what you don’t know — we need to make sure we are constantly getting feedback from others and constantly improving. Even the two weeks gap between sprint retrospective might be too long when giving feedback.

Ian wraps up his talk by giving two insights on learning in an Agile manner. First, it’s important to remember that we should model the kind of environment we want to work in. Our teams won’t be agile if we aren’t agile. Second, we have to take into consideration that the best practices for others might not be best practices for us as well. Our teams, products, and markets are different — what worked in other teams might not be the best approach for ours. Lastly, it’s not enough to be agile in terms of product delivery and be the first-mover in the market, we should also be the fastest-learner such that we experiment all the time and learn fast.

How do you communicate to stakeholders about bugs that aren’t part of the specs?

For the succeeding part of the event, we entered into the fishbowl format to discuss the various concerns that the audience raised. The first topic was about how and when do you communicate to stakeholders about bugs for user stories that were not really part of the specifications. The main theme of the responses from the audience was that product managers needed a certain level of transparency and negotiation to make sure that as we communicate the issues to our stakeholders, we can accomplish what we need to, and that the stakeholders are aware that the issues exist, but will be dealt with separately.

How do you build psychological safety?

As the audience delved deeper on why we would encounter a situation where the team wouldn’t be comfortable talking about the bugs to stakeholders, we realized that there was the deeper issue of psychological safety in play. As we discussed psychological safety, various viewpoints were raised. For some, they felt that product managers should shield the team, particularly the developers, from the stakeholders. The rationale was that the stakeholder’s input had to be filtered since a lot of it usually doesn’t make sense at first, and will be a waste of the developers’ time. For others, they felt that it was better to get the developers to talk with the stakeholders — this was risky, but it also helped the developers to build their defenses better. Others also felt that the key to building psychological safety was to build it yourself and at the same time, demand it from the top leader in your organization.

How do you communicate better with developers?

As we continued to talk about building psychological safety, especially with the developers, the discussion began to shift to how to communicate better with the developers since as product managers, we didn’t want to disturb them unnecessarily. A couple of advice from the audience were:

1. As a manager, protect the “zone” time where the developers are focused on coding (usually afternoon), but make sure catch-up and talk time outside of the “zone” time (morning) is meaningful
2. Pool things you want to ask, write them down and wait for a time when the developers are ready to talk
3. Observe your developers. Having earphones on would usually be an indication that they don’t want to be disturbed. You could also check if they’re no longer doing work-related items since that usually means that they’re free to talk.

A couple of developers in the audience also gave the insight that as developers, they also care about the product. In some ways, they do want to get disturbed immediately for urgent concerns that would affect their current workload like critical bugs. However, the ask is for the product managers to judge what they should be disturbed immediately about since topics like a new feature request could be discussed in the sprint planning meeting.

Should the DevOps team be a part of the sprint planning?

We then jumped into a more technical topic about whether the DevOps team should be a part of the sprint planning. The question was rooted in a context where the feature developers are actually ready to push a new feature out, but the DevOps team isn’t able to deploy it into production. The initial set of reactions from the audience revolved around involving DevOps as part of the sprint planning — whether this meant including the DevOps team to the meeting or making sure that even the feature developers can do DevOps work. This triggered another set of reactions where people debated whether there was a need to have a separate DevOps team at all. Some of the audience who belonged to the Banking industry felt that the stringent standards for banking applications meant that they really needed a separate “production” team. On the other hand, others felt that it had less to do with industry and had more to do with making incremental changes so that they are safer to deploy in production.

What do you do when you have an ineffective product owner?

The next topic was about how to deal with an ineffective product owner who was looking to leave their role. In particular, what do you tell a product owner who is not able to manage the stakeholders well, and consequently, creates more work for the development team. In response to this, the audience mainly felt that Product Management is not for everyone. It’s a high-stress role where you really have to manage a lot of stakeholders. Others advised to introspect if the product owner won’t be effective in the next six months to a year. If they won’t be, then try to lead the product owner into thinking that they need to leave on their own. There was also a heavy emphasis on getting the Product Manager to own the product — that is, do whatever it takes to make the product successful.

As a team member, how do you influence decision makers to create a great work environment?

As we were beginning to wrap up, the conversation shifted into how do we actually foster a great working environment. After all, most of us were team members, and the decision makers above us were the people who actually had the power to foster the changes required to create psychological safety. In response to this, the audience gave three specific advice:

1. Understand what works as a communication style for you — As an individual, you would have a specific communication style that you are most comfortable with. Some people are more comfortable with being direct, while others are more comfortable with being more tactful. Some others may prefer to have validation first before even engaging in a difficult conversation.
2. Understand what medium the recipient understands the best — Different people have different ways of understanding concepts and ideas. Some people are more visual, while others are better readers or listeners. Some people don’t want confrontation, and some others are more receptive to ideas that they think they came up with.
3. Reflect back to yourself — At the end of the day, if you don’t have the courage to do it yourself, how can you demand it from others. That is to say, the question “How might we change others” can be re-framed into “How might I change myself”

Do you prefer product managers who you only see during meetings versus those who you see every day?

We wrapped up our event with the topic of what is your preferred kind of product manager: the kind you only see during meetings or the kind you see every day. Both sides could work, and both sides could fail, but the audience shared some interesting insights on this dynamic. The core insight was that you can choose to invest more time in having written documentation early on or pay the price of spending more time talking to your teams on a day-to-day basis to clarify what needs to be done. In most cases, a new team will typically benefit from a more present product manager since the environment of the team will typically shift on a frequent basis, hence the documentation becomes irrelevant frequently, and you will need to talk to your team frequently anyway. On the other hand, a more mature team will likely find such a product manager to be unnecessary and will likely appreciate a well-written documentation better as it gets the job done faster.

Be part of our ProductPH Facebook group to get notified about the latest meetups here in the Philippines: goo.gl/Um75dV