Projects or Products to Drive Transformation?

Projects or Products to Drive Transformation?

Your boss called you into his office and has given you the great news. You have been assigned the task of leading a crucial effort within the company to transform the way customers place orders for your top revenue product line. You’ve been charged with creating and implementing the mobile digital customer experience, and the company workflows needed to implement the changes. You are excited to max as this is the sort of responsibility you have worked towards your entire career.

You get back to your desk and realize the scale and significance of the task at hand and ask yourself, “Where do I start now?”

If you are like most mid-level managers with a few Projects under your belt, you start to envision the business transformation Project, the team members, and maybe even you pull out your Microsoft Project For Dummies book since it has been a little while since you led such an important and high-profile project. You make your team member list, you think about the timing and delivery objectives of the Project, and even anticipate what happens at the end of the Project if things don’t fully get implemented. You make detailed Project primary and fallback plans. You have 6 months and you hurry to call your Project team to order to get the Project underway. You figure before talking to any potential users, you want to formulate the plan of attack, scope out features, and start making project, lest you get sidetracked with too many end user features requests.

Sound familiar?

There is however a different way to think about how to manage this fundamental Digital Business Transformation that you are charged with leading and delivering. It turns out that this conceptualization has been fundamental for years to how companies deliver Product or Service value to customers. The conceptualization also fits the case where internal operations need to be streamlined or automated to drive cost savings within the business.

Introducing Digital Product Management

Instead of thinking about a Project, think instead in terms of delivering a Product. I take an expansive view of what can be called a Product. A Product is not only a physical good that is packaged for delivery to a customer. It can be a Service that is performed by your firm’s personnel, or it can be an Internal Workflow that automates a process that was previously performed through labor intensive manual steps. Products are bundles of value delivered by a company to its customers that make things better for those customers, internally to the company or externally.

Agile Concept Development

Whereas a Project has a distinct start and target deadline for completion and delivery of an outcome, Products live over time. Just because a deadline has been set the delivery of a predefined set of features does not mean development and refinement of the Product is complete. Thinking in terms of a Product means you think about Version 1.0, Version 1.1, and Version 2.0 of the Product Line. You can map out a Product Roadmap that lays out over time the capabilities envisioned for delivery to the customer. 

Products are built to the requirements of the customer. Every Product has a customer, whether it is the consumer of your company’s product or service, or the Executive Team and the Board of Directors seeking to internally drive Digital Transform of the business for future profitability. An important step in any Product Creation Process is to formalize the approach to the capture of Product Requirements. The approach to capturing requirements may vary based on the size of the team and the size and scope of the Product. A smaller team (e.g. 2 – 4 developers) working on a smaller Product can use work product created via short development cycles to capture and document Product Requirements. At the end of each development cycle, the customer is walked through what has been created and provides immediate feedback on the work completed. Larger more complex Products need to be defined and documented more rigorously, typically using team collaboration tools (e.g. Slack or Atlassian Confluence) to create a structured hierarchy of feature sets (also called Epics, Users Stories, or use Cases). Refining requirements takes place throughout the entire Product Development Lifecycle. It’s important to show progress to the customer throughout the entire process. Short bursts of development activity help to enable more frequent capture of customer feedback. While Agile Development is all the rage today, the core concepts of iterative development based on more frequent customer feedback have been established for over 25 years. What has changed is there is massive proliferation of information technology in business and the need to leverage it for competitive advantage and profitability.

When viewing your Digital Transformation challenge as a Digital Product Management process versus and Project Management process, you also will tend to think about key financial considerations differently. First is consciously undertaking a “Make vs. Buy” decision. When faced with a complex problem to solve, rather than just building a system or new workflow from scratch, it is valuable to consider 3rd party vendor that off-the-shelf or semi-customizable solutions. The investment that Enterprise System Solution vendors make in creating scaleable, robust, and fully tested platforms is significant. Will you be able to get more value for your investment? You should carefully consider if building a solution internally will provide a better return on investment than what’s possible with the implementation of a commercially available off-the-shelf solution. So, do perform and initial due diligence on solution vendors. Stack them up on a per-feature, license model and implementation cost basis and compare the potential results to what you believe may be possible with an internally created solution. Finally, when you create and manage internal or external facing enhancements to your business as a Product, you will take a more complete view of the financial impact of the investment. Rather than focusing on the costs of personnel in a Project, you will quantify tangible and intangible costs, model potential cost savings, forecast revenue streams, and build into your financial model total cost of deployment and support of the Product with multiple Version Releases over time.

Changing your company’s mindset from working on Projects to working on Products will require a change to your corporate culture. Existing team members that may be adept about thinking about a Project may not immediately transition to thinking about Product Roadmaps, Customer Requirements, Product Launch Plans, on-going Customer Feedback, and Marketing and Sales (both internally and externally). However, a Digital Product Management Approach to driving business Transformation will lead to more robust and customer-centered solutions. The change in mindset is well worth the effort and change.

Share on linkedin
LinkedIn
Share on twitter
Twitter
Share on facebook
Facebook
Share on google
Google+
Share on pinterest
Pinterest

Leave a Reply

Close Menu