Are people fleeing in terror intensely simulating labor activity having seen you cross the horizon? The inefficiencies of the contractor are missing deadlines and backsliding on their agreement? All people are crazy incompetencies out there, and you can’t take your eyes off of the whole development cycle? Yes, the situation is not easy. It is possible that the second side of the conflict also has something to say, though!
Almost 10-year experience in software development & implementation has taught us that a professional relationship is not white and black. You can and should find an approach to any client and focus on the results if you want the idea to get off the ground.
Nevertheless, with some customers, we had chemistry almost from the first phone call, and as a rule, this was the beginning of a long and fruitful relationship that led to more than one joint project being released. While someone else made us wade through thorns up to the stars synchronizing our everyday actions step by step and establishing an effective dialogue.
There may be tons of pitfalls in IT development. But today, we’d like to talk about one of the most critical participants – product owners. Who are they, and how can they affect the effectiveness of the business plan implementation?
Product Owner: Introduction
It is worth opening any manual of flexible development – and you’ll face them – professional knights in shining armor – the eyes, the ears, and the voice of the Customer. They understand the general idea of the project, are responsible for the vision of the final product and its value to the user.
You can talk for a long time about the project, what it should be or not, but here the main thing is that almost everything depends on the actions of product owners.
And now we ask you to imagine the situation when the owner of the product somehow stalled the development, and it took days, weeks, and even months to make it great again. That’s where our story begins.
Image 1. Product owner: “Here is the task, let’s go… Go, go, go”!
Once, he swoops in the developers’ life with a fantastic project and a chic long read that mainly explains what, how, and when should be done. At first, that’s more than enough. But the project is gaining momentum, and the gears of a perfectly calibrated mechanism are beginning to come across circumstances. Some points need clarification. The others have been forgotten at all (since only to Cassandra the gift of total foresight is given, no one ever believes her, though), somewhere our specialist saw an opportunity to optimize the functionality. There are just too many things it could be.
Solution: Good communication. Ideal product owners are ready to discuss current issues with the developers every single day during periods of high activity. After that, as a rule, it is enough to meet once or twice a week. They can hear and listen to the team, clarify, concretize and prioritize their actions, and are not afraid of any deviations from the original plan, guided by the principles of efficiency. Again, the ideal owner of the product.
Image 2. Imaginary friend
After all, only some of us can afford to keep our duties in mind and do them well. While the others are frequently overloaded and duty-bound to spend their time on irrelevant questions, there is nothing to be done about it. But you have to find the way because ignoring the problem won’t make it go away.
For example, in one of our projects, the product owner was so busy that he could not answer our emails not only for days but sometimes for a whole week. As a result, the process was hampered: ready-made features were not approved, questions had a way of snowballing, and we could not take new tasks to brighten up somehow the painful moment of waiting.
Our project manager did her best to communicate with the product owner via email and the messengers. But it wasn’t a real solution. At best, the product owner replied: “Yes, yes, today you will receive your answers.” The time zone difference also added a bit of drama: since the Customer’s team was in the USA, “today” automatically turned into “tomorrow.” Of course, we had meetings, but the list of questions had become so huge that it was simply impossible to discuss everything by that time.
Solution 1: Castling. The problem was solved quite easily. Since our product owner was involved in many projects, it was decided to offload him a little and give our project to another specialist who could pay more attention to our team.
Of course, the most specific issues were still resolved with the previous product owner for a while. But one thing is obvious – after this forced castling, the project accelerated significantly. 15 minute daily meetings do wonders, whatever you say.
Solution 2: Delegation. The overall workload of a project is indeed quite common. And in a similar situation, other product owners we collaborated with decided to delegate the part of his duties to his subordinate. And this is also a good option, except for one thing – the deputy’s lack of appropriate authority (and some experience, cause being a deputy means you want to learn something new from this leadership) to make critical decisions. Nevertheless, such a move helped significantly reduce the team’s stress during the development process: most issues were resolved relatively quickly, features were clarified, bugs were fixed, and the caravan went on. What more could one ask for?
Image 3. Mr. Late
What if your product owner is the fairest in the land, providing the project’s mission, vision, and values, being ready to detail and prioritize tasks, and open for dialogue, but… Let’s wake up and think about what to do if the product owner is regularly late for meetings, such as one of our partners. There were plenty of reasons for those endless delays, and, admittedly, most of them were objective. Thus, there were many force majeure circumstances when he just ran late at some previous and also urgent meetings. That explanation did not brighten our days, though.
Solution: In general, the situation was not critical. It was always possible to shift something in the schedule. Plus, since nobody likes a meeting that drags on with no purpose, writing a meeting agenda facilitated our interaction greatly (when it finally came to interchange). Plus, we could discuss some issues within 20 minutes of waiting and provide a final version.
Image 4. What are you guys doing here?
Sometimes it is difficult for product owners to overcome their natural distrust, especially when working with an outsourcing company whose developers a million states away are so busy doing stuff all the time. OMG, what if it’s a fake and they are playing solitaire more than working on a project??? In this case, only time can help, which, as you know, heals all wounds and allows the team to demonstrate their competence.
Solution: To speed up this process, with one customer, we had to release step by step every week: it brought him comfort and wasn’t a problem for us at all. A business trip to the client’s head office was beneficial in another case. At first, the product owner tried to work in a primary school teacher mode: walking around our guys and looking into the monitors, ensuring they were doing their tasks properly. But continuous communication and joint hard work did their job – and we did not raise the question of confidence again.
Image 5. …And I’m a tech proficient, among other things
It’s no secret that competent product owners should understand the technical component of the project. In an ideal world, their previous experience in development is even preferred. Nevertheless, the division of responsibilities is a fundamental principle of any teamwork. Roughly speaking, the encoder encodes, the business analyst analyzes, the project manager manages, and the product owners.. own 🙂 You should not be embarrassed that some technical aspects are a little out of your league. It’s just not your showtime.
This is a subject close to the previous problem of trust. Once, a client had a preconceived belief that IT people, to put it mildly, are… not the most intelligent people. And that at specific points, he’ll be the perfect man to solve any technical issue.
In such circumstances, it is a bit difficult to show your competence, because when you work for a powerful man… sometimes the collar can get a little tight. Our product owner constantly demanded to provide him access to various databases. He intended to write queries himself since our statistics or reports seemed “incorrect” to him.
Solution: Of course, we provided access to the product owner in that situation. But. Soon after, a series of questions followed: “And what is this?”, “And how does it work?”, “And where should I click here?”, Because the database was somewhat complicated, the tables had a massive amount of numbers , and, of course, it was challenging to work having no specific background.
In global terms, both in words and deeds, it is essential to deliver the information to the client that IT people are about code and deep business analysis of the product, development strategy, and guarantee of its successful functioning after release. Moreover, in the end, a job is not just a job for us. The beginning of a new project is akin to adoption. We must get your idea off the ground and make it competitive and as effective as possible to be proud of what we did.
Image 6. This is how product owners roll
Sometimes the line between the objective factors affecting product development and the subjective preferences of the customer is blurred. One product owner we collaborated with was an excellent specialist – he described the features pretty well, provided clear and detailed comments, and quickly responded to our requests. But there was one thing that seriously hindered the plan’s effectiveness: little by little. All the features began to adapt to the tastes and preferences of the particular person, ignoring the jointly developed and approved strategy for the project implementation. “Something is uncomfortable for me here,” “And here I would like to …”, “But somehow I don’t like it …” – those were the mantras increasingly heard from him.
Solution: Of course, your project is your child, and you always want it to be precisely the way you imagine it. However, it is worth considering the opinion of other participants in the development. Just imagine that your child needs to get from point A to point B by scooter, but suddenly you are told it’ll be better to use a bicycle, and don’t forget about the helmet! No, not the blue, but the red one. And it might also be worthwhile to include a couple of stops in the route to increase the endurance. And one more thing – your child doesn’t want to be a football player but dreams of ballet dancing. Now live with it 🙂 We mean, everything isn’t very much without teamwork in the development.
In the case mentioned above – after a while, the Customer was forced to delegate the responsibility to a more objective candidate.
Image 7. Guess what I had in mind?
There’re moments when the customer cannot imagine how their system will function. In such cases, a lot is expected from the development team that has to formulate a clear concept and strategy for its implementation, which is not bad for competent specialists. But only if the client is ready to accept someone else’s vision of the problem.
In our practice, there were cases when the product owners were entirely for the development strategy, shared our desire to do cool stuff, and create the most demanded platform. But this desire was not always accompanied by the information on how this will happen. He could give us a small sketch: “What I would like.” But when we came for details, sometimes the answer was, “I don’t know what exactly I want, but you think it up.” It was not always easy to work with.
Solution: In that specific situation, we were fortunate: our tech lead was pretty much immersed in the business domain, making it easier to articulate and fulfill what product owners wanted from us. But this fact did not shield us from various controversial issues during the acceptance stage. Indeed, when even the client himself cannot clearly explain how and what he expects in the end, then “surprises” cannot be avoided.
Image 8. I’m not sure I understand you
Any outsource company, sooner or later, is going to go down the road of cultural differences. And it’s not even a matter of diametrically opposing mentalities – pitfalls are often hidden behind the smooth surface of seemingly ordinary backgrounds. For example, the eternal contrast between the American friendly style and restrained Slavic expression is an old true story about a misunderstanding. Or concise (and so professionally neutral in some countries) answer “Got it” missing a healthy dose of small talks, all the attention and etiquette issues may not only mislead but offend your Partner.
Solution: Your client needs to be talked to in the language they understand. This concerns not only words but also the manner of communication. This approach has many positive aspects because close acquaintance with other cultures only enriches us spiritually and makes us open to the world.
Image 9. Just call me The Slasher
This case is probably the most difficult one. After all, there’s always a possibility for a graceful end to any situation. So long as both sides are ready to be engaged in dialogue and compromise for the common good. But what to do when there is a little bit of… conflicting helmsman in the project?
Once, we happened to cooperate with a very complicated product owner. Indeed, much more could be said about their pros and cons as a person and a specialist. Still, the main distinguishing feature that significantly influenced the development process was their short temper and uncompromising nature. Their craving for conflicts was especially intensified during online meetings in conversation, oddly enough, with other customer representatives. Consequently, working hours used to turn into holy wars about every little thing, and we could only get popcorn and stock up on patience.
Solution: the conflict died down and flared up again for several months until our “problematic” product owner showed himself as a true professional. He made a truce with his colleagues, and they agreed to leave our meetings, appointing another, more neutral product owner. After such a wise decision, the atmosphere in the team became much calmer.
On this, our tale of a problematic client comes to an end. Indeed, you have your own stories about the obstacles on your way to successful teamwork and how you overcame them. What is the moral of this fable? There are no unsolvable situations. We will work with you even where others file for divorce, referring to “unmendable differences.”
Need experienced product owners or any other manager to dig into all peculiarities of your project and keep the development process on track? You’ve come to the right place! PieSoft Business Analysis and Project Management Services are at your disposal!
