A lines in the sand

I’ve been working on three new pieces of work for the Shop product this week. They were all requested by stakeholders and the expectation based on previous experience is for the Product Manager to write up the request in a Work Request document and submit it to IT for them to undertake some investigation and come up with an estimate. This way often resulted in other parts of the organisation not being involved when they should be and work being undertaken that was of low value, so I don’t do it that way.

My way focuses on value. I use a broad framework of discovery, definition, development and delivery to guide the work. Discovery is the first step, but there isn’t an assumption that any piece of work will progress past that phase. The work has to earn it. It’s important that the success metrics for a piece of discovery work is defined at the beginning. This isn’t only to ensure that the project will have sufficient value, but to know whether we’ve reached that line in the sand before proceed to the definition stage. For example, one of the pieces of work is about a sever upgrade so the lines in the sand are about security and performance. If the discovery work doesn’t show that the upgrade will improve security and performance then there isn’t sufficient value in doing the work and my recommendation will say so.

It was interesting to explain to stakeholders the benefits of this work and show them that by clearly understanding the value up front, and setting a line in the sand that tells us whether there is value in continuing with the work, we can prioritise to achieve the most for our efforts.

Product Team Playbook

I spent some time thinking about how to help the PM’s shift away from the usual approach to work that is to ‘get on with the obvious thing in front of me’ to a more thoughtful, questioning approach that encourages the Product Managers to have more robustness in their practice that produces more reliable results. This robustness will come from adopting an open and flexible framework such as the Discover, Define, Develop, Deliver double-diamond model that I’m working on.

This model is in response to the issues I see of PM’s spending too much time working in the development and delivery space, which has greater complexity than it should because the PM’s haven’t spent enough time doing the discovery and definition work earlier. I’m aware that I need to provide more concreteness about how to do discovery work to understand the value that can be created and captured, so I decided to write a playbook. It might be that it only serves as a way for me to structure my thoughts, or it might evolve into a tool the team can use.

The purpose of all this is to help PM’s understand that their job is to convert ambiguity into certainty for the organisation, and how to do that job better. A playbook is a step along the way in them internalising that thinking so that they don’t need a playbook and are relentlessly focused on value.

Creating a picture

As we work on the new product we’re developing more and more we’re gradually creating a clearer and clearer picture of what it’ll look like and how it’ll work. We’ve been working:

  • Capabilities & Features – Capabilities are groups of features, and the features define a specific piece of functionality. Defining all the features tells us how the product will work, what data we need to provide, and what priority we need to apply when we start building.
  • User story mapping – The user story maps we’re creating describe the steps a user goes through in order to accomplish a task. We are associating the features that are required for each step to the map so that we can check that we’re building the correct functionality to enable that journey to happen.
  • Wireframes – We started with lo-fi mobile designs to spark conversations about what should and shouldn’t be on a webpage. Mobile first is important because, well, its the twenty-first century, and because it makes us be more considered and disciplined about what we put on a page and how we structure it.
  • Persona – The personas are created on axes of experience/seniority and size of organisation. This enables us to create content that meets the differing needs of a junior user at a large organisation, an expert user at a medium-sized company or the CEO of a small business. We’ll also map the content into influencer journeys so that nothing exists in isolation and every piece of content leads on to another.
Personas

Next week we’re beginning to share this work with stakeholders to get feedback and more importantly to communicate some of our thinking around the product strategy and design which is quite a departure from our current approach.

Idea of the week

I ‘presented’ (ok, I chatted about) the idea that in order to support machine interpret-able standards we need to change the way standards are written. Currently, standards are written through a long process of committees of experts producing a document, and if we wanted to make the contents of the document machine interpret-able we would need to understand the context of use and apply a taxonomy for the data, but that the problem with this is that we aren’t able to know the context or what taxonomy and data our customers might need in the future.

So, the solution to this is to create standards in a different way. Stop writing documents and start writing just the data that is machine interpret-able. We still won’t know what context and taxonomy apply but we’ll be able to iterate so quickly on create the standard that we’ll be able to start with any taxonomy, put it in front of customers and quickly develop towards the create taxonomy for any hyper-specific context.

Scared penguins

The question is, who are we in the video? It’s one of those ‘open to interpretation that reveals how you think’ questions. The usual answer seems to be that the penguins all worked together to defeat the orca, so we’re the penguins. My interpretation of the video is that the penguins aren’t working as a team, they are acting as individuals each motivated by fear. The fact that they are all driven by the same fear creates the illusion of alignment and teamwork.

Later that day, someone for HR came over to me and said in a bit of a whisper that there was something I had to do because someone had ‘escalated’ it. I took from the look on her face and the tone of her voice that I was supposed to be scared by this. I did the thing I needed to do, it wasn’t a big thing, just one of the many things I hadn’t gotten around to yet, but it left me feeling a little baffled. I’ve haven’t encountered that kind of penguin fear so blatantly before, although I’ve seen plenty of under currents.

If we’re supposed to be the penguins, it raise the question of who is the the orca? Is the orca the one who seizes the opportunity, takes control, initiates? Is the orca the senior person that was escalated to, are they the ones that represent the fear? Or is the orca anything and everything that scares us to all exhibit the same behaviour?

If you’re going to be a penguin, be one of these penguins: