Product Management vs Development Team View on Feature Definition and Implementation
Both in product companies, and outsourcing organizations you can find people responsible for the product launch, and technical specialists who deliver the product. We call it “product” and “technical” people. First ones are responsible for defining new features, providing and understanding the business domain, while technical people are responsible for actual feature implementation. You may ask: “how can the expectations of product and technical teams be so far apart from each other and why does it happen?”.
The Main Conflict Between Product Owners And Developers
The point is, usually they got no technical expertise to truly understand how does the product work and how to implement the things they need exactly. Also, for this reason, product people often have trouble explaining the task to the engineering team, designers, developers and other specialists. They need a result, but often they have no idea how to get from the point A to point B. The conflict of interests starts at this point. Technical people (mobile ios or android developers, server-side developers, QA engineers, etc) need proper description and detailed requirements to the exact task. Just a high-level vision delivered by product people isn’t usually enough for the successful development. The essence of the conflict between product and technical people is related to the level of detail provided to the tech stuff (related to mobile development as well). Also, product people can have a different view on time estimates, acceptance criteria and cost estimate. Products do not enjoy decomposing tasks to the bricks, but the implementation team needs a description to the task that is as detailed as possible. Sometimes both tech and product people think they live in the different worlds and speak a different language. You can see the most vivid example of this conflict by watching the well-known sketch-video The Expert. Another real life example from mobile app development world (ios specifically), which illustrates the difference in approaches: Product: I need a sliding table that shows my customers’ data and usage statistics. I think it should not take more than 4-6 man/hours to implement as we have all the data in DB right? It’s a small task, am I correct?Developer: Well. 4-5 hours does not look feasible.Product: What is so complicated about a small sliding table?Developer: let me ask a couple of questions: What exact columns are needed? How should the “sliding” table work correctly? Do you need sorting? Search/filtering on this table? You mentioned usage statistics. We store in separate DB. So have to find a way to bring in the data. Are there any date constraints on usage data? Product: Yeah. I thought it was your job to decompose the task and think about all these details. However, well, if you ask. So columns A-Z I guess. Slide 20 rows a time. Sorting - yes. We need search I guess. Moreover, I’m interested in statistics for the last 2 months. Let’s make rows clickable and add an ability to go into detailed view for a specific customer. However, I am not quite sure about all this. Maybe the conception changes during the process of development. However, you know what to do.Developer: Sure, thank you for the details. Let’s take a look. So this involves changes in the IOS app, API, services, DAL, database changes. It takes around 5-6 man/days. Also, if you would ask for some changes during the process, please notify me ASAP, because they can take even more time. What I gave you is an initial estimate, that can change if any additional requests come.Mobile applications seem so easy-to-change; however, the truth is, that implementation of every more or less significant feature requires changes on every layer, from UI to DB. Here is an example of how do these layers may look like:
Well, if you remembered any real-life situation happened to you while watching the video or reading the dialogue, you are not the only one. The misunderstanding between the product owner and developer is a common problem. Doesn’t matter, if we talk about IOS or android, UI or server side, mobile or web development, changes involving the client or server side, or both.
How Can Product People And Technical Specialists Understand Each Other
I worked a lot with both small and big developer’s teams with pure mobile projects and big platforms that had IOS application as its small component. Also, I always faced this conflict between product and technical people. Now I want to provide you with the list of tips that work and facilitate interaction between engineering and product teams. - Product owner and developer might discuss any new feature before the actual development work starts. A developer should ask as many questions as he/she needs, and the product might patiently describe all the details to the developer. It’s better to spend more time on the initial discussion than remake everything in the last moment.- Both sides might clearly understand the level of complexity and efforts required to build-up a feature. That’s why the developer might clearly explain why he/she needs the named amount of time, no more and no less.- Product owner and developer might develop their soft skills to ensure effective communication. Negotiations about the feature implementation is not a place for emotions and double meanings.- It’s always better to arrange a call or meet in person for the discussion of details. - A developer should not rely on the documentation only. Sometimes technical people have to initiate meetings because product people can forget about this.- Each side might try to understand another for real. It’s not only about the technical terms, but the way of thinking, turnkey problems and details.- Do not hesitate to ask questions even if it seems that you understood 80% of all information and can google 20% of it. It’s always better to understand 100% of the task and do what is in the technical task, work as a team.- Be ready to answer dumb questions. They might seem so because your opponent has an entirely different way of thinking. Explain as much as your colleague needs.- Discuss. Bring your ideas, suggest approaches that you think might work. Don’t hide it.- A tip for the tech people: study your business domain properly, try to think big. You might understand how the whole business is functioning and what is the role of the application you develop in this big picture. Doesn’t matter if you are developing ios or android application, building reactJS front end or implement server side services - If the team is big, bring a role of proxy business analyst. This person contacts with the product owner, finds out the list of his major requirements and explains this information to the team of developers. It is like a translator or facilitator for application development. BA is 50% product and 50% tech person, and this allows him to facilitate the negotiations for both sides.- The product owner must define the tasks and the goal of the project. You can ask some specialists to do it for you, but only if you have a big picture in your mind. Nobody can explain the purpose and the tasks better than the person who invented this product. If you implement at least some of tips from this list, the workflow on your project changes significantly. Just give it a try.
Tips And Tricks For Product People On How To Make The Development Process Efficient
Every development process involves several fundamental roles. One team member can handle two or more roles, but before starting a development process, consider your team includes these roles: - Product owner,. Role responsible for product specifications, features- Project manager. Role responsible for development process. Doesn’t matter you are agile (scrum, kanban, scrumban), waterfall. You need PM role- BA or system analyst- UI/UX/Graphic designer. Crucial for mobile ios and android b2c applications- Front-end developer- Back-end developer- QA Engineer- Client Service If you hire a large team, there can be many designers and developers and testers as well as other people. However, the point is, all the roles must be present to facilitate your app development and delivery process.
How To Select The Best Partners For Your Application Development
Technical expertise and experience are not the only things you might take into consideration while selecting the team to execute your project. There is a checklist for helping you to find the dream team among dozens of applicants. So, you might pay close attention to the team if they: - Understand your project, the problems solved by it and consider your project attractive and useful.- Are capable of carrying all the roles listed above. They can at least, in general, explain the duties of every role in your particular project.- This team has expertise with the technically similar project, and the projects they implemented before are worth paying attention. Again, it is not the most critical factor, but you might consider it as well.- They dig into detail before making an estimation and telling you the price of the overall work.- They are capable of dividing your projects onto the milestones and explain each stage to you adequately. Ok, you selected a team you like the most. Now think about the working model you are going to use in this particular project to enhance its efficiency. Generally there are three of them: - Fixed price or fixed budget. It is suitable when stakeholders understand the project. Requirements are not expected to change too much during the development phase. Everyone knows the budget for the whole project from the very beginning.- Time and material. The project is not yet well-defined, the terms and features can vary during the development process. The team estimates the project in worker-days or working hours, which have a specific cost.- Full-time employee commitment. It is suitable if your project is extensive and/or it requires lifetime support and enhancement. You pay a monthly fee per specialist or per team. Also, there are some basic terms and conditions you might include into every contract to avoid misunderstanding. These are: - For a fixed-price project you might consider the deadline and penalties for its non-compliance.- The budget and fees. Fees belong more to the time and materials model, but you can use it as an addition to the fixed-price model. For example, when your team finished the central part of the project, but you liked the way the team made everything, and you want them to add a couple more features. By the way, you might describe the mentioned possibility of prolongation in the initial contract.- Describe all the roles and responsibilities of the team in the contractual agreement.- Use the Gantt chart to show the project timeline in the contract.- You might mention milestones that can also be called verification points. Dividing the large project into milestones might help to avoid misunderstanding when it comes to the payment.- Mention that the intellectual property rights of the work result transfer to you after you paid the amount mentioned in the contract. To conclude, I have to mention several techniques helping to keep the project on track: - Ensure close and instant cooperation with the project manager and CS Executive.- Set up weekly project calls or meetings. Every meeting has to cover the project status, an evolution of the Gantt or Jira burn down chart, issues and problems encountered and solved, project delays and extra specific information. You can arrange meetings more frequently if needed.- Keep an eye on the milestones executed and don’t forget to deliver the payment according to the contract signed.- Test the project on the accomplished intermediary stages. Give on-time the feedback to the team.- Provide your team with all the materials, conceptions, visions and ideas asked by them. Give them a clear understanding of what you want to see in the very end. I hope that this guide is useful for those of you who are about to build engineering team and start bringing your ideas to life. Good luck, and pay attention to detail ! If you have any questions or suggestions, feel free to write it in comments to this article.