How to build and launch an enterprise-scale product

Enterprise-Scale Product Management (Part-1)

Swapna M
Swapna M
Jun 24, 2018 · 9 min read

Creating products for a startup or for experimental ventures within a corporate is one thing, but developing & launching enterprise-scale products often take the form of a colossal project (even if it’s done in a lean agile mode).

To give you a bit of context, by enterprise-scale products, I mean —

  • Products created within the walls of a multinational corporation in traditional industries such as banking or healthcare
  • Products bound to get adopted by 80K+ users on day 1 possibly for enterprise (B2B) clients
  • Products normally created in collaboration with inhouse business partners (eg. the HR team might want a digital retirement planning solution for its employees) or a product that can be sold/licensed/subscribed to/by other companies/enterprises (eg. Sunlife creating a digital health benefits solution for its clients)

This complexity and gargantuan initiative is due to a variety of factors — the number and kinds of stakeholders involved, the reputation/brand of the company at stake, dependencies and collaboration with 3rd party vendors and business teams, risks of entering a brand new market, mandate of putting our best foot forward & achieving company objectives (no longer playing the MVP game here) and more.

Whilst there might be many counter arguments to the way described above, getting a product from ideation to launch and beyond in a large corporate setting is no easy pursuit as a product manager. There even might be multiple product managers or an entire product team dedicated to get this enterprise-scale job done.

To tackle this, many organizations and digital teams of large corporations (eg. Mastercard, Deloitte, Cisco) follow the approach outlined below to get a valuable product out to the market as quickly as possible :

  1. Innovation — Reimagine the customer journey / pain-points / job to be done
  2. Ideation — hypothesize on what is possible to appease the user painpoints
  3. Incubation — rapidly engineer/design the technology
  4. Commercialization — launch and scale the product

This article will cover the steps involved to make each stage (innovation, ideation, incubation, commercialization) a success by improving processes, reducing complexity and alleviating the risk of oversight, with the end result of creating products that have positive impact on clients and users alike.


Innovation comes in various shapes and forms — here are some of the steps involved in innovating in a large corporate setting :

Keep a lookout for innocuous customer pain-points in those measure and learn sessions or those regular customer interviews/surveys. Innovation can be triggered anywhere, anytime. It doesn’t require a process or a team or a diktat. Innovation just needs embracement.

It can take the form of an engineer coming to the broader team and informing that a new technology would make the application performance 30x times better. Or a marketing manager bringing a new way of growth hacking into the team. Or a project manager trying to transform the team structure to resemble self-contained squads. Or a team member bringing some user insight back to the team and the entire team getting excited to explore it further.

Creating a product without understanding the target audience and the market is a fallacy you don’t want to make when the stakes are so high (time bandwidth, resources, brand reputation).

Hence it’s imperative to understand and identify the target market, user pain-points, or more specifically, the user’s job-to-be-done. This can also involve being cognizant of the opportunities or trends in the market, in your industry or others (eg. the adoption of facial recognition technology in the cellphone industry might disrupt the banking industry in the future — imagine financial advisors verifying their clients and opening bank accounts using facial recognition, hence nullifying the need for the client to walk into a bank branch).

It is also paramount to question —

  • What exactly are we trying to solve?
  • Is this the right problem to solve? Is it worth solving for?
  • Does this problem align with our company vision? Does it align with our long term strategy?
  • Are there any existing solutions in the market that solve this need? Is it worth collaborating with them or creating our own version of the solution with a key differentiator?

Answers to these questions and more would provide you with a skeleton of where you want to focus on and place your next bet.

Yes you read that right — the most overused word in a product team — “design thinking”. But these workshops do happen regularly to encourage product teams to empathize and experiment to arrive at innovative solutions to solve complex, often ambiguous/ill-defined problems. This might involve reframing the problem in human centric ways, having brainstorming sessions, some quick prototyping and testing, ethnographic research etc.

So yes get a few immediate stakeholders from your team, have an offsite workshop, bring out those ideas, explore and examine out-of-box concepts, question existing solutions and create an environment where disruption is the norm, not an exception.


Once a high level concept has been redefined and has been prioritized in your roadmap to explore further, here are the steps involved to get some traction within the team :

Hypothesize the kind of solution you envision to get the job done for the user. This can take the shape of a high level business case that will be key to your project in order to keep the product vision alive. This might include -

  1. Product vision
  2. Problem statement
  3. Hypothesis
  4. Target market / audience
  5. Customer value
  6. User persona
  7. Business objectives
  8. Success metrics / North star metric
  9. And more..

This is a good reference document to have in order to reiterate the vision to the broader team at all times. And if anyone digresses at a later stage without reason, you could point them to the business vision as was initially outlined in this document.

Identifying the work-streams required and aligning the different teams/stakeholders for their input into the project is key. Right from engineering, quality assurance, UX/UI design, visual design, business analysis, project management, scrum (masters) to market research, marketing, analytics, content et all.

It is of utmost importance to identify and anoint one lead or representative for each work-stream, given that not all team members can attend every single meeting at all times. I’ve seen cases where all members of a given work-stream try to attend every single meeting they’re invited to, with the end result of creating immense redundancy, wastage of time and resources and even miscommunication / misalignment of what needs to happen.

The owner of each work-stream needs to collate the requirements and decisions made from each meeting and communicate it to their own team and vice-versa — all the questions, feedback, end collateral needs to be represented by the owner to the wider audience. This creates a single point of contact for communication instead of relaying the entire team at all hours. It also helps in having better alignment within the team since roles and responsibilities are assimilated and acted upon in ease.

Having backup leads for each work stream is also important to avoid unexpected project calamities.

Some amount of pre-work is required before you can bring the outline of the entire project to the wider audience/team. The product team needs to collaborate with the work-stream leads with what you’re trying to solve and the business vision of this product. These leads might already have been involved with the design thinking workshops or brainstorming meeting, so they might already be traveling with the business problem to solve. This allows the leads to come up with some high level outline of their individual expertise— be it user journeys/flows, technical architecture, data flows, tech analysis, project estimates, resource and launch plan etc.

Note this part of the process can take up the majority portion of the time, as expected. It is better to spend more time in planning for a large scale project (understanding dependencies, aligning different team and business stakeholders, delineating the ROI and success metrics, creating a resource plan, timelines, budget and much more!) than going ahead with the incubation phase without a holistic plan (getting to the execution phase quickly might be a good strategy for a proof of concept or a startup trying to fail fast, succeed sooner).

Identifying the Project cadence (agile, waterfall, kanban etc.) for the incubation phase is key here too. This may take the form of an agreement (eg. agile agreement) with our 3rd party vendors or business partners. This will form the basis of how each party is going to collaborate with each other on this enterprise scale project.

Having a kickoff session where the vision, business objectives, high level milestones, userflows etc. for the product/project is communicated to the entire team (members from all workstreams) helps in having a cohesive team that understands #why are they building #what they’re building. This session can involve -

  1. Drawing the business vision / Problem statement / Hypothesis
  2. Enumerating the key high level milestones or objectives
  3. Describing the user flows
  4. Explaining the solution architecture
  5. and more.

This session can also be utilized to define the definition of done (DOD) and definition of ready (DOR) at the start of the project, to keep everyone on the same page, and to manage expectations (eg. Is a desktop mockup enough to start development, or would they want mobile and tablet versions upfront before starting development). Negotiations can play a key role here.

This is also a place to ask and answer lots of questions, make the team feel valued and boost the morale of the team in commencing a brand new chapter of their product.

Following up is the next step towards the way to incubation. This involves having weekly huddles for status updates from each stream, identifying risks, prioritizing the risks, Interdependencies between the workstreams (eg. dev depends on the business logic and calculations to finalize before it can begin) and forming a plan of action.

This stage is also critical to develop epics, user stories, detailed designs, dataflows, datamappings etc. for the different features envisioned for the business-case.


To be covered in another post..

A preview —

  1. Sprint cadences

2. Regular user touchpoints / feedback

3. ‘Beta testing’ functionality

4. Guerrilla testing/measure and learns

5. Getting more workstreams involved — marketing, risk and compliance, sales, customer support, production support etc.


To be continued in another blog post!

UPDATE : The second part’s here : Incubation & Commercialization

If you like this article and have questions or feedback regarding product management in a corporate setting, leave a comment below!

And also let me know the process and challenges in your organization?

Agile Insider

Exclusive & practical insights about rapidly delivering value.

By Agile Insider

The best of Agile Insider delivered to your inbox Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Agile Insider

Exclusive and practical insights that enable the agile community to succeed.

Swapna M

Written by

Swapna M

Product Lead @RBC | #Fintech #Innovation #Payments #AI | Previously Head of Product @ Klood, @Scholastic, @Accenture |

Agile Insider

Exclusive and practical insights that enable the agile community to succeed.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store