Did you know that the price of a polished diamond can be up to 30 times its price as an uncut stone?

In other words – the demand for the stone after cutting and polishing it becomes 30 times higher. Pretty good deal indeed.

In this post, I will talk about how the product and development managers can polish the product and raise its value, much like what happens when polishing an uncut diamond, and while doing that, motivate the R&D team and enjoy the process.

Agile or Waterfall, in both cases I saw how the most talented QA and development engineers prefer to just get the product requirements and focus on implementation. One of them expressed it quite well: “I am an expert in providing answers, not in asking questions”. There is nothing wrong with that, but that’s a huge missed opportunity. After all, they are the ones that know the product from the inside out and are able to predict how a change in one feature will affect the others. So how can you harness the knowledge and abilities of the QA and development teams right from the start – before the actual work begins, before the first sticky note is posted on the SCRUM board?

What works for me is what I call “Monday Product”. It is a meeting that goes like this:

• Meeting name and frequency – every two weeks we had a meeting titled “Open House –Monday Product”. Open – because it wasn’t necessary to show up. Monday – because it was held on Mondays. Product – because during these meetings we discussed different parts of the product.
• Participation is not mandatory – I emphasized that participation wasn’t a must. It doesn’t matter how many people show up, two or 30, as long as those who show up choose to be there. This way, you will guarantee maximum attention and maximum commitment. There were only two people whose presence was a must – the functional architect and the product manager (If he was abroad, we used the phone or video conferencing).
• Aligning expectations – When opening the meeting, I emphasized that we will be separating the creative part (in the beginning of the meeting) and the execution part (afterwards). First, everyone shares their ideas, without rolling out any of them, and only when we are done, the best ideas are chosen and we examine our ability to implement them.
• Meeting contents – First, the customer’s persona is introduced (e.g. CSIO). Then, you present his/her problem as well the product’s parts which solve this problem (if they already exist). Next, you open the discussion to everyone.

At first, you might get a cynical reaction (Oh well, yet another way to kill an hour and let out some steam). Don’t give up. If you really mean what you say, the doubts will disappear once the first idea makes it to the product’s backlog.

When “Monday Product” meetings become part of the development process, the effect is huge:

• Getting a polished product that does the work – sometimes the details that come up in these meetings make a huge difference in the planning. For example, we were once asked to develop integration with enterprise SSO products. During a “Monday Product” meeting we learned a small fact – some of our customers provide our product as a service so we had to plan for federation. The initial design was thrown away and replaced by a new one. The product guys knew all the details, yet engineering and product had to cooperate in order to bring the right solution. Simple and clear.
• More effective development – developers and designers who understand the purpose behind the requirements will work more effectively. They are more likely to avoid overdesigning and less likely to put their efforts on unimportant stuff or to forget crucial content
• Motivation – last but definitely not least, the whole development team, including the most cynical engineers, is bought into the process. Everyone knew why every step was taken and I could hear lively arguments in the halls, not only about how to write and test the code, but also about what would be best for the users. This attitude generates a constant flow of ideas and improvements.

And before closing, do you also have a way to get the development team to use their talents and work with the product team during the requirements defining phase? If so, please, share it with us.

Good luck!

Ilan