We agreed we need someone to take ownership of product operations and excel at that
We want a structure that will stand up for the next 6 months
Do not design for legacy; design for the customers we want to have imminently and the products we want to support e.g., LGIM, HSBC
Accept there are many "right" ways of doing this
Everyone in Tumelo should be selling and thinking strategically
We agreed we need someone to take ownership of product operations and excel at that
Now we need to define that role specifically, and work out how to make sure that role is not a single point of failure (holiday, illness)
Need to define what is Product Ops vs what will stay in data team @Kathryn Armitstead
We have agreed that Jade, Chris, Aline are well placed to take on product ops responsibilities
We need to decide where that role will sit in the
We need to agree on the roles and responsibilities of Sales, CS, Operations, Prod etc. in progress, Georgia - to discuss on Monday morning
Gaps? We need to work out which other roles we are missing to succeed with pass-through voting - in progress, Georgia - to discuss on Monday morning
Voting Operations – create great processes to conduct voting through proxy intermediary and support risk control
Working across teams to help consistent communication and to identify areas for improvement within PTV, EWO and Institutional operations.
Handling d2d responsibilities re EDI and GL coverage and creating processes In line with proxy advisors.
Scoping operations needed for PTV (key focus) and EOW Institutional/Shareholder
Defining and documenting operations for PTV, EOW Institutional/Shareholder
Working with teams to ensure they understand their roles and responsibilities within the operational framework
Embedding the processes within the business and ensuring that the business is working towards the applicable standard associated with the product
Ensuring the business is aware of risks within the operational processes and ensure that mitigating actions have been put in place
Ensuring we have the correct monitoring and alerts in place which allows us to mitigate and control issues arising
Ensuring that the operational processes that are put in place meet the SLA’s set externally
Understands resourcing demands and supports the business in meeting those demands
Manage pipeline
Drive initial sale
On-going account management - looks after the strategic interests of the customers
Fund up-sell/product expansion
Re-contracting
Part 1: Client Operations (Tom)
Manage customer implementation - fund manager and asset owners - provide project management so the customer can extract value from the product
Support sales with on-going account management requests e.g. MI packs, presentations
Service on-going customer needs e.g. customer support, training, reporting, quarterly reviews
Manage relationships with non-strategic, legacy customers who do not warrant strategic account management from sales
Outreach to FM's to receive product applicable data
Part 2: Product Operations (Jade)
Service on-going product operations - ensure the product operates well on an on-going basis as the product manager (and customers) expect.
Vote operations
Data operations
Data/product supplier contracts
Service monitoring
Ownership of the EDI relationship
Data Ingestion and the responsible for the accuracy of the data ingested
Data monitoring reports created to identify data issues and support vote operation procedures
SOP's in place to deal with regular data procedures including identifying and dealing with errors
The team will essentially be an engineering team and operations team for the time being
Manage the product roadmap and ensure the product does what customers need it to do now and in the future.
Wyc is owns the relationship with the proxy Intermediaries - Broadridge, Proximity
Stuart owns the relationship with the proxy advisers
Client invoicing
Commercial modelling
Will provide engineers to design and manage the technical aspects of the implementation project, and support sales on technical questions e.g. solutions architect
Data Management and Security
DevOps
Software development delivery
Data co-ordinator at Tumelo
FMP at Tumelo
Gathering and collecting data from multiple 3rd parties. Managing relationships with credit reference agencies, media outlets and their circulation lists. I scoped out workflows and risks attached to these.
I started the ISO9001 accreditation before I left and joined Tumelo. Identifying 3rd party suppliers, documenting processes re auditing, responsibilities, risks etc.
Oversaw data accuracy, completeness etc. We had specific processes in place to view age, coverage, volumes and would complete ‘quality control’ checks.
Developed, questioned implemented SOPs
Managed a team of 18 people including Sales BDMs, I.T Software Developers, Email Marketing Executives, and Telesales Operatives
9Fin
Asset managers buy bond market data from them - ticket size is +£50k
150 ppl, USA and London
No COO
They have someone who runs their data team who started as a grad at the company and now does data + runs others who do data; they report into the CEO.
Finbourne
Asset managers buy asset servicing platform/data - ticket size is £250k+
300ppl USA and London
Leadership/ops structure: CEO, Global Head of Sales [sales team, solutions architects], Global Head of Client Delivery [account managers, project managers, technical implementation managers], Head of Product [product operations + other product people], CTO [Engineering], COO [customer support, legal, IT, Office, Cyber, liability], HR [People Ops]
Note: they change their structure ALL the time, and don't have all the questions I asked nailed by any means. We were debating what was best on the phone. There is definitely not a "right answer". We need to play to our strengths and weaknesses to make this work for us, today.
So sales make a sell, bring in account manager really early. Implementation is LONG. Then the Global Head of Client Delivery is running the show. Once into BAU they hand over the Head of Operations, who has the customer services team, who will intro themselves to the customers and explain how support will work from now on. At that point, an Account Manager would be assigned to run that project. Most repeat business would be managed via Account Managers, not Sales Managers. But that's actually being debated at the moment internally. People disagree about whether that's the best way to manage things. And they don't have enough data to say one way or the other.
Responsibilities | Ownership now | Notes |
Common operations | ||
Design minimum-viable, and then scalable versions of ops processes for all products | Unowned | DL: Should be Ops but realistically is being shared by Tom, Phil, Wyc... I've reworded this to clarify that it's the minimum-viable ops process - not the min viable product which obviously is product/tech |
Set up operational monitoring and alerts across all products | TW - CS use the monitoring tools with clients. WS - Monitoring will change with PTV as will the need to have an efficient process for handling issues that arise. I don't think existing tools/processes will suffice. DL: Needs to be much more mature. | |
Manage, meet and adapt external SLAs we commit to for each product | TW: We have some contractually and we also have some CS guidelines which confirm how fast we can get data ready. WS: We need to reframe the historic thinking of only getting ready for a launch of a new fund for PTV. For PTV to succeed, we must be maintaining and monitoring the whole process proactively and performing all the necessary manual processes efficiently and in a timely manner. DL: CS should own the SLAs as they are managed between Tumelo and customer. Internally ownership is more granular, eg if they're tech-based such as page load time, the instrumentation, monitoring, alerting should be owned by tech teams. Ops would own operational SLAs relating to, for eg, manual processing of votes, timeliness of adding companies to the system | |
Implement due diligence, reporting and review processes across all products | WS: Agree most of this should transition away from needing day-to-day involvement of product team. | |
Third-parties as they relate to products - EDI, SFTP feeds from custodians, proxy advisor APIs/SFTP fees, Broadridge CDF etc. | DL: This is like a Data Ops role. A bit separate to Ops in the customer support, data entry sense. Ultimately is Ops but may not be the first thing to hand over in this list. WS: I think there is a reasonable argument that the product team retain relationships that are required to support the generic product functionality (e.g. EDI), but less so for partner or customer-specific integrations (e.g. custodians). In my previous lives this kind of work would be owned by a separate "delivery" team. | |
Design and manage client UAT plans | CS | DL: Part of implementation role, which I believe is in Ops |
Contract MSA/Order Form ownership - overseeing the standardisation and control of contracts | CS | DL: Think we have this ownership, but it still feels rather hectic, so hopefully legal ownership can be baked in here as an expectation of the role |
Pass-through voting/Vote Operations | ||
Asset owner holdings monitoring | DL: Data Ops | |
Fund manager position files monitoring | DL: Data Ops | |
Meeting monitoring | DL: Data Ops | |
Proxy recommendations - e.g. chasing if they are late | DL: Data Ops | |
All other systems monitoring e.g. notifications, email alerts etc. to meet customer SLAs | DL: Depends. If it's monitoring that a piece of tech has failed entirely, I think alerting should be owned by the tech team, and the fix as well. If it's monitoring the customer SLAs over time, that's Ops/CS imo | |
Working with ProxyEdge
| TW: CS working towards supporting this process DL: Ops | |
Verification, quality assurance processes, checking everything is right | DL: If this relates to checking the processing of a PTV is right, then Ops. | |
Reporting and disclosure processing, to FMs and other | DL: Data Ops - although I think setting this up to be do-able may be part of the product. Needs clarity | |
Plan for how many people are going to be required to operate the process | TW: I am looking into DL: Ops | |
Organise our of hours rotas/holiday cover etc | DL: Yes for customer support, no for engineering rotas TW: With vote submission deadlines this is going to be needed WS: We have tried to arrange vote submission timeframes so that out-of-hours working is not required as standard, however what happens when we're all at TumX? Someone will need to be running Vote Ops. We are bound to need some level of out of hours support too, especially for critical infrastructure problems. | |
Expression of Wish Specific | ? | |
Transparency API Specific | ? | |
Shareholder Platform Specific | ||
Creation and deployment of new shareholder platforms | DL: Currently requires a % of product squad's time to deploy and maintain. Unlikely to change given we don't have these skills in Ops - but goal should be to build self-serve tools for Implementation team in Ops | |
Support | DL: Support part of Ops | |
Retail support | CS | |
Asset owner support | CS | |
Fund manager support | CS | |
Custodian support | ? | |
Third-party (e.g. ISS) support | ? | |
Notification / comms to customers (eg notifying of an outage) | DL: Customer support | |
Notification to users (eg notifying of update to T&Cs) | DL Customer support | |
Third-party integrations/partnerships | ?? TBC | |
Custodian integration process and maintenance | DL: I think these are part of tech teams DL: Ideally product make a repeatable process so that implementation team can set these up repeatedly for new clients. In the absence of this, Product/Tech would likely own WS: Agree, in absence of a "delivery" team, the data team are the most obvious owners of this. | |
Fund manager integration process and maintenance | DL: As above | |
Fund administrator integration process and maintenance | DL: As above |
Responsibilities | Ownership today | Should ownership move to ops role? | Notes |
Oversee end to end operational processes at Tumelo, across teams and products, including smooth handovers between teams | DL: Very broad definition - needs breaking down. TW -
| ||
Training for operational teams | TW - CS/FMP have historically trained within team | ||
Internal SLAs | TW: needs more defining on what we are referring to here | ||
Ensure processes and operating model remain compliant with market practices in multiple geographies | TW: I would expect this to sit with product DL: I'm unclear what is included here WS: Agree that product need to understand how functionality may need to adapt to local markets, but that may also come with the need to adapt our operational processes, which should be owned by the operations team. | ||
Customer success e.g. Maximising value of existing customer relationships and contract renewal | DL: I think CS, implementation and legals sits within Ops part of business - ownership depends on what this role becomes (ie a junior Ops person won't own, but a Head of Ops would) | ||
Service third-parties e.g. lawyers and Vendor relationships: Review vendor costs and validate fees paid on a monthly basis and seek to enhance vendor services whilst ensuring value for money. | DL: I think Ops should 'own' legals and thus lawyers would fit. Depends on what else fits this category TW: my experience is that a procurement team would do this work DL: In the absence of that (ie we're too small for procurement), generally I've always seen these owned by the most logical team for the service | ||
New products e.g. PTV | DL: Ops should be involved in setting up operations alongside software development | ||
Assessment of non-standard sales opportunities | |||
Others: transaction processing, customer support, risk management, ensuring compliance with regulation, business continuity planning, vendor management and reporting. Client Accounts (payments), New Business, Transfers, Corporate Actions, Stockfile, Helpdesk, Client Services (complaints). |
Responsibilities | Ownership | Notes |
Back-office product/roadmap | Duncan | DL: Ops should be the stakeholder, Product the owner |
Working product definitions | Duncan | |
Driving team efficiencies, moving faster, being leaner, de-risking processes e.g. automation | All | DL: Depends what is meant by this - every team should be doing this for their own area TW: Agree with DL |
Documentation (gaps in) | All | DL: Yes to operational process documentation, but not software documentation which is owned by tech teams TW: Teams should take ownership of their own documentation |
Tracking COGS, owning product P&L over long-term | Duncan | DL: Needs more consideration, but doesn't feel like it's an Ops-owned thing to me |
Testing processes | Andy | |
Release process | Andy | |
Culture | Laura | |
People Ops | Laura | |
Horizon scanning | Georgia | |
Long-term strategic planning | Georgia | |
Software subscriptions e.g. Hubspot, Nuclino | Laura, Lisa, Emma | |
Data-driven decision making | All |
The reporting structure of product operations may vary depending on the organization and its specific dynamics. In some companies, product operations may report to the head of product, while in others, it may report to the head of operations.
Both structures have their advantages and considerations. Reporting to the Head of Product:
Alignment: Product operations closely supports the product development and management functions. Reporting to the head of product ensures a direct alignment with the product strategy and goals.
Expertise: The head of product typically has a deep understanding of the product vision, market, and customer needs. Being under their leadership allows product operations to benefit from their expertise and insights.
Collaboration: Product operations teams often work closely with product managers, designers, and engineers. Reporting to the head of product facilitates seamless collaboration and communication between these cross-functional teams.
Proximity to Decision-Making: Being part of the product department places product operations near key decision-making activities. This can allow the team to have a better understanding of the strategic direction and priorities of the product, and they can more directly influence those decisions.
Potential Drawbacks: The potential downside is that this arrangement could make the product operations team overly focused on product-centric issues, potentially overlooking broader operational aspects that could impact the business as a whole.
Reporting to the Head of Operations:
Efficiency and Process Orientation: Operations leaders are typically skilled in process optimization, resource allocation, and scalability. Product operations reporting to the head of operations can leverage these skills to drive efficiency and streamline workflows.
Holistic View: Operations leaders oversee various functions and have a broader view of the overall business operations. Product operations reporting to the head of operations can benefit from this holistic perspective and contribute to the alignment of product initiatives with broader business objectives.
Emphasis on Operational Excellence: This structure can help ensure that product operations are well-integrated with other operational functions in the company. This can lead to better alignment in processes, tools, and best practices across all operations functions.
Potential Drawbacks: On the downside, being distant from the product management team could create communication gaps and result in less alignment between product strategy and operations. The product operations team may also not have as direct a path to impacting product strategy and decision-making.
Cross-functional Collaboration: Operations teams often collaborate with multiple functions across the organization, such as finance, HR, and IT. Reporting to the head of operations can facilitate effective coordination and alignment with these functions.
Ultimately, the decision on whether product operations should report to the head of product or head of operations depends on the company's specific organizational structure, goals, and priorities. It is crucial to consider factors such as the company's culture, the nature of the product, and the level of cross-functional collaboration required for successful product operations.
In some companies, a hybrid structure could be employed, where product operations reports to both the Head of Product and Head of Operations. This could provide the best of both worlds, but also has the potential to create conflicts if the priorities of product and operations diverge.
Customer Support: are they trained on the new product, how and when is the launch taking place, staffing numbers - do we need to increase numbers and/or will there be spikes in contact that we need to account for, rotas/shifts to cover all hours, holidays and sickness, SLAs around things like answering calls and responding to emails, templates and pre-written answers to Qs to ensure fast and consistent responses, clear processes documented for things like complaints and dealing with potential fraud.
Business continuity: what happens during a disaster or significant disruption, what backups do we have in place, do we have everyones up to date contact details
Transaction processing: have we calculated how many people we expect to need for manual data entry, does this number change or fluctuate across the day/month/year, hiring and lead times to train people, clear processes documented to ensure fast, consistent and auditable processing of information
Risk management: what controls are in place to mitigate risk, what are our risks and are they documented, what checks are in place to prevent errors and fraud
Reporting: can we report on KPIs in terms of things like number of applications completed, errors, processing time, what regulatory reporting do we need to provide, risk reporting in terms of things like errors, downtime, compliance issues.I definitely agree that we have a bit of a gap here at present. Tom is picking up some of this, particularly in relation to Customer onboarding, but possibly stretched too thin to cover all the PTV ongoing activities, processes and risks in enough detail. Hope that's useful.
Aviva Workplace
Aviva's operations were good at managing scale so they were solid at things like embedding fool proof processes. They were pretty awful in my experience at treating customers like customers and not treating them like a process.
Operations within Aviva covered:
Day 2 Day Customer support at all levels from pension/insurance customers through to employers and Trustees
Customer helpline: queries, complaints, requests for info, transactions ect
Providing standard reporting
Administration tasks linked to BAU product tasks such as processing transactions or correctional work
Aviva had a sales and business development department (Distribution) which covered the below and worked very closely with operations. There were 3 parts to distributions: New Business, Existing Business and Operations. Operations covered: Big team (tendering), Implementation Team and some of the operational support teams that helped the existing business team mostly.
Building and expanding on relationships with clients
Building relationships with advisers
Onboarding
Tender processes
Project work for specific clients
Aviva also had departments that specifically covered:
Investment Management
Actuarial and Risk
Marketing
Legal and Compliance
Technology
IMO
One context of operations is servicing BAU demands of the business and I do think that this work sits in a specific operational area
Other things above that we are defining as operations above like documentation and end to end processes should be owned by the specific teams that uses them. Agree there should be company best practice around it but the situations that I have come across where another team owns a process or the docs that another team must use results in lots of red tape.