Growing Teams with Team Meetings – Making Things Explicit
My last post was on the difficulty on identifying opportunities for team work. This one is closely related and is about growing teams.
There are many things that make working on physical products and services much easier than in the non-physical world.
But there are at least two aspects which make our work harder in a strange way:
- Most of us don’t have an explicit economic model of what our product or parts of it (features) do. (I wrote about this here and there and mention it in all my trainings and workshops – expect a blog post on it sometime!)
- Our product is not tangible and thus we have to take extra effort to make it so.
(I suspect that the latter leads to the former, btw.)
Working without having a product experience
Coming from my post on team play, here is the problem:
We often start from a great idea of how something could impact some metric, behaviour, outcome. That is a totally theoretical construct. Which then leads to ideas of e.g. interface changes, API changes.
Work on this great idea is often delegated in the following way: A Product Owner gets the task to think about that concept. Once he has an idea of what to do, he breaks the whole thing down, comes up with a mock up here or there (if at all), and finally fills up the backlog in form of an excel spreadsheet or Jira tickets (duh!).
He then explains the “stories”, tickets or backlog items to “his” development team and … finally things are done (done).
Often, of course, the backlog items stem directly from explanations of stakeholders that ´just want something’.
In both cases, very little thinking and feedback happens. In the physical world, working this way would be a no no. We only invest in the development of physical things after some scrutiny, as coming up with a production chain and the necessary supply chain is already a heavy investment. The missing economic model in SW products leads to us “doing things”. (Main objective: All teams have things to do – we manage resource utilization.) A lack of team play in a product group leads to a lack of reflection on what we actually do. (And, oh boy, trust me: I failed and failed this way again and again.)
Long story short: This is not a way we can gather feedback on the experience of the product, make it experienceable on any way to anyone and thus we have no feedback on what we are doing.
How do other disciplines do this?
Turns out, we are about the only ones working this way. (The reason again: the missing underlying economic model of what we are doing.)
If you design door handles for a Porsche, BMW or Opel you will have to present your designs on a very very regular basis.
If you are editing movies, you will present your results to the director, producer, marketing again and again. Actually, the whole creative process of editing a movie relies on continuous feedback.
If you are writing a book with a publisher, guess what: you will get constant editorial feedback on several layers – from orthography, over style to content.
Nearly every profession relies on a continuous feedback process to get the thing right. It’s just us who like to drool behind our laptops, crunching around Excel sheets, sorting data upside down, map reduce the data in our minds and what have you. All on our own. We’re on tech after all. (And yes, we complain about having to talk to stakeholders all day.)
How I make the product more team-workable and experiencable
Here’s how I do things. And what I would urge you to do as well. Even though not everyone will like your medicine on first sight.
I set up a regular, weekly team meeting (of Product Owners). It takes two hours at least. But four hours are ideal imho.
In the meeting I have everyone presenting his latest version of the product or product part that he is working on and then we group critique, harden, rinse and repeat the whole thing.
That leads to everyone thinking about how the product can be experienced, made tangible and explainable. That alone leads to a different approach and thinking about the product.
And, yes, I hear you cringe: Isn’t that “control”? Isn’t that robbing you of freedom, autonomy and what have you? I say: Yes, maybe. But I also say: I don’t care!
I want you to build a product you can constantly explain, show and demonstrate. Just like the devs need to always have working code. It is my responsibility that the product will be the best we can deliver. And I know: it will be better with all that critique from the whole product team. This is not about you and your ideas, it is about the product.
But here is my promise to you: You don’t have to take my feedback and work on it. Also that of your colleagues. All I want is you to listen to it and then do with it what you think is right. You are a grown up person. But I want you to get all that valuable feedback. Remember, we are a team!?
Another promise: At times, with good reason, because you have to go down that deep rabbit hole of a new concept, you are excused. You don’t have to show anything. But maybe, you have something to tell us of what you current area of research, newest hypotheses, designs etc. are? Maybe we can help? Maybe we can help you get out of the rabbit hole sooner?
And yes, as I said: we will do this every week. Two hours at least, better yet 4. You say it’s a lot of time? Then tell me how you spend that time better? And why we should do things differently than any other creative job?
BTW: If you have a hunch why we don’t normally work this way, I am happy for any input on that. As to me it is a riddle. Really: I have never come up with anything deep and meaning full just on my own.
Photo credits: Thanks to the University of Michigan School for Environment and Sustainability for the above photo, picked up at flickr.