How to become a better product manager in MENA

Photo by Campaign Creators on Unsplash

Some of the most innovative ideas come from existing employees. They just struggle to make it through the organizational pipeline.

Business managers regularly pitch product concepts, but most remain on the drawing board, with actual launch and implementation being the exception rather than the norm.

Managing the development of new digital products and applications internally, means upskilling existing staff from multiple lines of business to become better Product Managers. This means empowering them with the ability to own projects, the knowledge of what skill sets will be required and how to think about creating business requirements and budgets.

Read this guide if you’re looking for help on how to get your company project from idea to live pilot!

SECTIONS

• Product Ownership
• What your existing IT department can and can’t do
• Business Requirements — the start of all great Product Development
• How to think about budgets and objectives

TAKE OWNERSHIP!

Most business executives complain they don’t understand enough about IT to take ownership of a project. They also feel IT teams don’t understand business enough in order to have a productive conversation about creating new digital experiences for customers. At the same time, the general consensus is that the IT department is responsible for buying and implementing any new technology. This is a formula destined for failure.

The first task to overcome in the development of any new product is appointing ownership. When it comes to the delivery of new digital products and services, consider how existing technology is used / owned / operated in your current organization.

Typical ERP software is a core software that might be implemented by an outside consultant, used by finance and stock teams, and “maintained” by IT, who are also responsible for any problem resolution. In this scenario, who is the real Owner of the ERP as a product?

What about marketing software? Even if the IT team wasn’t involved in the procurement (perhaps because the tool was priced below certain thresholds) it’s likely that they’re going to be loaded with the responsibility for ensuring it works as required and further customization requests.

The product owner is the key person in the client organization for any software project, The product owner works with users, stakeholders, technologists, and the vendor to envision the direction for the product, with an eye toward delivering value to end users as quickly as possible. They therefore do not have to come from any particular department or have specialized technical knowledge. Instead, they should know the users of the desired product, the way the business operates and any constraints.

OUTCOME OF OWNERSHIP? FASTER DECISION MAKING

A strong product owner ensures that the vision is clear, the strategy is clear, there is space for teams building the software to learn, and that they are building or buying the right thing to incrementally show value to users. They are empowered by their agency to represent stakeholders in making rapid product decisions without the need for many layers of approval. This positioning ensures that the product owner understands everything that the development team is doing and that the needs of the client and customers are fully represented.

This is different than typical project management in IT. The product owner won’t have detailed project management charts or a comprehensive plan for the next 3 to 5 years. But they will have a vision for the outcomes that will be delivered to users, and have a path to executing.

UNDERSTANDING DEVELOPMENT VS OPERATIONS IN IT

IT is a very broad term. Non-technical business managers should start thinking about IT in terms of Development vs Operations. Typically the existing IT team in an enterprise is mainly concerned with Operations.

IT Operations take responsibility for the performance of existing servers, websites or databases.

Operations teams keeping existing services available, meeting agreed upon Service Level Agreement (SLA). Operations teams tend to prioritize Stability.

If you want to know if your IT team is Operations oriented, look for job roles such as:

• Infrastructure Support
• Network Engineer
• System Administrator
• Operations Support

Development on the other hand is all about change and iteration.

Development teams prioritize producing new software and applications and ensure that users get to use it as fast as possible.

Development Roles:

• Software Engineer
• Mobile Developer
• Front End Developer
• DevOps Architects
• Quality Assurance and Testing

Let’s go back to the marketing software example. Let’s say you’re using an email software provider we’ll call it “MailingBunny”. MailingBunny has been developed by a completely different set of people than your internal IT department. It’s been built so that non technical people eg marketing staff, can easily operate it, but; what happens when you want to make specific customizations or changes or integrate it with other parts of the business? How much can and should your IT department be involved here? Who’s responsible for security?

Let’s consider another example: An internal business unit is looking for a solution that would speed up or semi automate some of their processes. It will likely entail creation of a mobile app. Who should be responsible for the design and development of this app? The IT department? Obviously not, but you’ll likely have to involve them as part of the larger procurement process because you don’t want to put a vague RFP out to vendors, you want to be as accurate as possible in order to get the best price.

The point of this differentiation is to clearly identify how and why you need to engage IT in the process of procurement, even if they aren’t going to be the owners.

The way to do this is by gathering Business Requirements.

WHAT ARE BUSINESS REQUIREMENTS?

Business requirements should inform every investment in new software and technological infrastructure. You don’t launch a new project, purchase a new piece of enterprise software, or develop a new process unless it’s in response to a core business need. But understanding exactly what that need is can be a challenge in itself.

Even after spending time, resources, and energy trying to identify a problem that needs to be solved, organizations can find themselves in a situation where there is a fundamental mismatch between what they have planned for and what they actually need.

Undertaking a careful business requirements analysis can help you avoid this mismatch. Taking the time to carefully identify, analyze, and document your core business requirements can lead to a smoother procurement process with an outcome that delivers measurable results.

HOW DO YOU GATHER BUSINESS REQUIREMENTS?

• Identify key stakeholders
• Gather stakeholder requirements
• Interviewing stakeholders
• Conducting group workshops and focus groups
• Developing test cases for users to run through
• Categorize stakeholder requirements
• Functional requirements: how a new technology product should perform for the end-user
• Technical requirements: a focus on the technology issues to be considered so that the solution can be implemented effectively
• Operational requirements: a focus on the operational issues to be considered so that the solution will be able to function for the long term
• Change management requirements: how to ensure the transition and adoption of a new technology solution will go smoothly.
• Analyze and interpret requirements
• Identify the highest priorities
• Determine which requirements are achievable and feasible
• Understand and address any conflicts between requirements
• Document requirements

Even with the best planning, this stage of information gathering can suffer from:

• Missing stakeholders
• Vague requirements — particularly if questions aren’t set up the right way
• Analysis Paralysis (inability to prioritize, everything seems equal)
• Communication Barriers

IT BUDGET PLANNING: HOW TO CONNECT EXPENDITURES TO BUSINESS OBJECTIVES

Whether or not you’re responsible for setting Budget projections, it helps to understand how to approach planning an IT budget, and how to connect spend back to business objectives. Remember you’ll already have completed a business requirements analysis so the objectives should be relatively clear.

The first thing to remember is that technology isn’t the end goal, it’s a means of achieving business objectives.

When you’re seeking a budget for your tech requirements, you’re really telling a story about the problems the organization is facing and the solution you’re proposing, the costs of that solution and how those costs will deliver the required outputs to achieve the business objectives.

To connect a budget item to a business objective, your business requirements can serve as a bridge.

What you’re looking to establish in figures here are:

• The dollar value of the business objective
• The percentage that meeting a specific requirement will contribute to achieving that objective
• How much should be assigned to that requirement in the budget

Let’s say the company makes $100,000 sales per year, and a business objective is to increase sales to $120,000

You estimate that the sales team could save 50% time in admin if they had a solution that better processed customer data, meaning they could do 50% more sales.

The business requirements analysis imply a CRM platform is the ideal solution. (it could have implied hiring more sales-people would be the best route to achieve this $20,000 increase in sales)

You therefore have up to $10,000 available to spend on a CRM solution

KEY TAKEAWAYS

This is a very simplified example but it’s easy to see how you’re now in a much stronger position to approach IT and engage them in the creation of a detailed RFP. You’ve gathered the business requirements and analyzed stakeholder input, and you’ve got a justified budget for the purchase of a specific tool.

IT staff can then create more detailed specifications including any necessary required features and integrations with current systems which will enable a faster bidding process with easier to compare supplier bids.

Depending on how your enterprise is structured, IT may be responsible for the entire procurement process, or, they may have to submit to a centralized procurement department. In either case, ensuring you have followed the key steps of Ownership, Business Requirements, and Budgeting will increase your chances of project success.