Ask your boss or manager to try out the product you are working on. If she has already been doing it, you can stop reading now, and please go and tell her that I like what she is doing and she should keep it up. If the situation is the other way around then there is something important you have to do: convince her to try out and use the product you are working on.
Do a simple exercise for me: take two minutes and put down three different things that you produce and are used by executives or managers in order to make [strategic] decisions. Here is my list: studies, status reports and synchronisation meetings. I assume that your list is quite similar to mine.
I’m developing software and unfortunately the software itself is not on the list. One can argue that studies, reports and meetings are about the software, but actually they are about what we are doing and not what we are producing (a classical utilisation vs throughput situation). They don’t hold any value and in most of the cases they make things worse: they affect your sense of reality, you won’t know what is real anymore.
Let’s say you are a project manager in an enterprise environment. Developers tell you that the software is great and it works as it is supposed to work. Testers tell you a different story: it is not even close to what they agreed on. How do you make a decision in this case? No offense, but usually you’ll pick a side instead of going to the test lab and use the real source of information - the software - to bring a third perspective to the table. Software is the reality, not the status report.
This is not a question of trust, it is a question of knowing what is really going on. During a meeting people may tell you that everything is going well, but when you open up your browser and look at the product which looks like the myspace page of a teenager, you will definitely start asking the right questions. This doesn’t mean that you don’t trust your colleagues, it just means you are simply getting closer to the reality.
If you are thinking about a demo meeting, I have to bring you bad news: the demo meeting won’t solve this situation. During the meeting, experienced people will show you how they use the product. Again, false sense of reality. Imagine that you’re buying a car for your wife, girlfriend or daughter. I assume you don’t care how the test driver can drive that car, you want to drive that car yourself and make sure that’s the right one for your loved one.
Here is a story about demos: we had a weekly demo meeting where we showed the product to the product owner. He nodded all the time and accepted our sprints, until he was asked to show the product to a new customer. It had looked easy during the demo, but when he actually tried to use the product, he spent almost one hour figuring out how to export some data out of the system. Since then, he’s been continuously using the product.
A friend told me this after he had read this post: blockquote I had a good laugh when I read your post and it reminded me how we do demos. Until today, almost every demo of ours starts with a quick briefing where the team members instruct the person who’ll do the demo where to click and where not to click if he wants to avoid 500 HTTP errors during the event. endblockquote
It is important that you don’t exaggerate this. I’m not saying that you must use the product all the time and ask for a new build every day. I’m saying that you’ll see the project from a different perspective when you occasionally have a look at the product. If you find it difficult to use the product, I’m pretty sure that your customer will find it difficult, too. If the new design blows your mind, it will blow your customer’s mind, too.
There is one more thing: your colleagues will appreciate your efforts. It is a pleasure to see and work with a project manager who knows and feels what the team is doing and is interested in delivering a better product instead of delivering a project.
comments powered by Disqus