How To Improve The Contribution Of Product People In A Technical Discussion

Albeit the role of product people, which is a general name for product owners or product managers, and their responsibilities change across different companies and industries, the duties of product people are a prioritizer, a communication hub, and a presenter for the product. Importantly, they are responsible for the ultimate success of the product. These different responsibilities lead to ambiguity about their daily routines. A typical day for product people includes checking emails, evaluating customer feedback if it exists, tracking business metrics, writing business specs for upcoming features, and meeting with other product people, stakeholders, and the development team. Even if these days are generally dynamic for product people, meetings riddle their calendars. The subject or takeaways of meeting with other product people and stakeholders is crystal clear for a product manager. On the other hand, technical meetings with the development team are sometimes overwhelming ones for the contribution of product people. I put forward four well-known tools such as Postman, Swagger, Charles, and SQL to make collective decisions as a team.

First of all, I want to summarize how Postman makes product people’s life easier.

Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so you can create better APIs — faster.
Although using Postman by developers and QA specialists is common, product people can use Postman to:

• Make communication faster. When product people define what new business requirements will look like, they ensure that the development team gets things right. They can make this clarification or definition with the help of any worksheet but formally Postman.
• Decrease dependencies on the development team. Think that a product manager wants to try or test a 3rd party API. If they don’t have any experience with Postman, how can they test it without the development team?

Secondly, I want to explain the advantage of Swagger usage to product people.

Swagger is a powerful yet easy-to-use suite of API developer tools for teams and individuals, enabling development across the entire API lifecycle, from design and documentation to test and deployment.
Like Postman, Swagger, which is a visualization or documentation tool for APIs, can be used by product people to:

• Estimate the development effort or project size. When product people know

- which APIs their domain has,
- what these APIs do, and
- how these APIs work,

they can estimate that the new business requirement will demand whether the development team will

- develop a new API and
- add a new field to the existing API.

Thirdly, I want to give examples about how product people can iron out some problems or define the crux of problems.

Charles is an HTTP proxy / HTTP monitor / Reverse Proxy that enables you to view all of the HTTP and SSL / HTTPS traffic between your machine and the Internet. This tool includes requests, responses, and HTTP headers (which contain the cookies and caching information).
Charles, which shows what client and server send and receive, can be used by product people to:

• Define the problem and rectify it quickly. Assume we added a new product priced at $ 100 to our system. However, the price of this product in the iOS application is $ 10. We checked the product price in the database and saw it is $ 100. What is the reason for this price difference in the database and the application? There should be a problem with API or application. It is time-consuming to define the problem source without observing the request and response of the iOS application. With the help of Charles, product people can see these requests and responses. If API sends the price to the iOS application as $ 10, product people will guess that the problem is related to API. If API sends the price to the iOS application as $ 100, product people will guess that the problem is related to the iOS application.
• Test their applications with a slower internet connection. Customers expect not to see no internet connection screen on a slower internet connection. So, testing in different internet signals (weak and strong) is a core use case, especially for mobile applications. Product people can adjust the bandwidth of internet connections with the help of the Throttling feature.

Last but not least, I want to briefly explain the importance of understanding where data lives in, even though knowing SQL is not vital for product people.

SQL is a standard language for storing, manipulating, and retrieving data in the database.

SQL, commonly used to access a large amount of data by a data team, can be used by product people to:

• Estimate the development needs. When product people know which

- tables their domain has and
- data these tables store,
they can define that the new business requirement will demand whether the development team should
- create a new table and
- add a new column to the existing table.

• Make decisions faster. Even if a company has a data team, product people always need to analyze the data to find new product opportunities and improve existing product features. When product people decrease their dependencies on the data team as much as possible, they can perform more troubleshooting and consume less time. After understanding the world of the data and not depending on another team, product people can demand new tables or columns to track the new business metrics.

It is obvious, these tools are not must-have skills for product people. Bear in mind that nice to haves are nice to have. Understanding the use and contribution of these tools by product people makes them closer to the development team. When product people and technical people get closer to solving a problem or delivering a new business to customers, the combined effort created is the key to success. The more synergy a team has, the happier customers will be.