Andy has officially been a Product Manager at Skyward for a year now, and it's been a good and interesting transition for him. His perspective on the part of the company that he's left (the one I'm still in) is a common source of discussion for us--we talk a great deal about the differences in the culture between departments, perceptions of the unnamed "other" in those departments, and how a lot of those components are an interesting kind of different. New jargon has made its way into daily conversations, too. I mean, I had heard "User Story" or "Use Case" before, but its frequency in our conversations has increased dramatically.
When Andy is looking at improving part of the product or if I run into some kind of an issue, we write it up, the first part of which is the user story. This is where we give context for the situation. It's not a "X is broken; fix it" or "the way you have to fix this is through these specific steps." Instead, it's a scenario, the "as a secretary, I need to be able to do X, Y, and Z." Then, the next step is explaining the hardship, how the situation is affecting you in that hypothetical role. If there are more angles, relevant history, or important notes about that situation, those details get added in later; if I have an idea for a solution, I put that in subsequent sections, rather than insist it's the only way to fix it. From there, persons like Andy can take a look at that situation and find a solution that meets the needs of that scenario, keeping in mind the full context of all users and how other parts of a proposed solution may or may not affect other components and asking more questions from users as necessary to get that full picture.
At work, I have started to think about clients' service calls in this light. Very often, I ask someone a question about their concern and I get the litany of the whole history of the question, which can start with "well, years ago we used to do our scheduling like this but now we have a completely different way," and I try to find a nice way to say "that's not relevant to what I'm asking you today" and steer the conversation to what is happening right now and where they're stuck. If the client tells me "the report has to have X number" or "the report has to look Y way," I instead direct the conversation to what the current problem is again, trying to get a grasp on what they're really trying to accomplish, rather than any prejudices on how one thinks it should happen--I might have a completely different feature or report that will meet those goals better or faster. Now, I break every call down into four questions: what is showing incorrectly, what should it be showing, how do we know it should be showing that value (state rule, local policy, compared to this other screen, etc), and where is it showing it. With those answers, I can get any problem moving in the right direction. If someone cannot tell me one of those answers and/or demonstrate it with screenshots, then we keep digging until we have that sorted out--maybe it's confusion on how X screen actually looks at data or we cannot find anywhere now that actually shows the original concern because someone has already fixed it.
Another important concept has been what I've labeled as the skateboard approach. If the client's user story is that they need to be able to get from Point A to Point B, they could be insistent that they need a Cadillac. Well, another client one swears an old VW Beetle is sufficient, another says a Nissan would be great because it's like their old system, and another still says they need a train. They all have the common goal of moving a body from Point A to Point B. It's not worth my time to make a train if a car will do, let alone arguing about the module of car. No one is moving from Point A to Point B if they're waiting for a car that everyone but one group is going to be disappointed it. So you start with a skateboard. Is it where you want to be ultimately? No, but at least in the meanwhile people start moving. Then, the skateboard gets revamped to a bike, the bike gets a motor. It is not the final goal yet, but people are moving and in the meanwhile, we are gathering additional data on what the final design might look like. The mode of transportation will eventually evolve into the average that meets the most needs. In short, the point is that a solution gets things started and can be improved upon later, rather than expecting a magic solution to immediately be enacted, complete and perfect.
Concepts like these have started making their way into how we manage our home. When Andy and I run into a problem, we'll ask one another some shorthand of "what's the user story?" which is another way to say "what is the actual problem we're solving for?" The person bringing up the concern has a moment to consider the real root of the problem.
For example, in our townhouse, Andy and I would trip over each other in the kitchen all the time. Counterspace was a hot commodity. We were mutually complaining about this frustration. The use case broke down into a "we need to be able to move efficiently in the kitchen without impeding the other" with additional notes identifying specifically "we need more counter space." Then, we started talking about potential solutions--the key difference here, though, was that we did not go in with any expectations that these solutions were going to fix the entire problem. We made suggestions knowing that these were things we could try and modify as time went by. This included ensuring that appliances were put away to optimize space, the first skateboard. We added to it a buffet that had additional drawers and counter space--getting into the bike stage. We were still tripping over one another, but there were more spaces at least to spread out a bit. We talked about how to take turns, but that didn't seem feasible when we were only home at lunch for a short time--added feature of the bike was removed. When we started looking at houses, how much counter space was there was certainly on my mind--this will be a very drastic change to meet the needs of that problem, but it is definitely going to help!
This has worked for emotional situations, too. I can bring up a concern to which Andy will ask me what I really need in that situation. I convert it to a user story. The user story format allows us to continue from a safer vantage point, still addressing very real, emotionally-charged concerns but acknowledging it for what it is, as something that needs to be addressed, and not assigning blame. Then we can talk more about the background as necessary or what affects other aspects. Then, as a team we start thinking about skateboards. We're not expecting it to solve the whole problem, but we're actively trying things to address it, opening the door to discussion and modifications later.
We're going to get a lot more practice yet as we move into our first house at the end of the week!
No comments:
Post a Comment