Internal CRM / Sales Technology
Owning the sales platform with Sales as the customer.
I turned an internal CRM that reps worked around into one they actually rely on, driving adoption to ~90% and giving each rep back roughly 4 hours a week. I did it by treating Sales as my customer: running recurring discovery with Sales Operations and frontline reps, turning their workflow pain into prioritized requirements, and shipping the fixes with engineering. This is sales-technology product ownership, from discovery to adoption.
The prioritization example tagged Illustrative is a representative recreation of the approach, not real data. No company, system, or personnel names are included.
The problem, my role, and the bar for success
Sales ran their day inside an internal CRM that had grown around the system, not around the seller. Reps worked around it with manual steps, side spreadsheets, and re-entry; Sales Operations spent time reconciling data instead of acting on it. The tool technically held the data, but it did not fit the workflow, so it slowed the people it was meant to help.
As Product Manager I owned that platform with Sales as my customer. My job was to understand how reps actually sold, decide what to change, and ship improvements that made the system match the work, while keeping the data trustworthy for the people downstream.
Goal
Make the internal CRM fit how Sales actually works, so the system speeds selling and produces data the org can trust.
Scope
In: rep workflows, data and fields, reporting and visibility, usability of the day-to-day surfaces.
Out: the later migration to a third-party CRM; commercial policy and quota design.
Success criteria
- check_circleReps adopt the tool, not workarounds
- check_circleFewer steps per common task
- check_circleCleaner, more trustworthy data
- check_circleSelf-serve reporting for Sales
Sales as the customer, on a steady cadence
I did not guess at requirements. I ran recurring discovery with Sales, regular sessions to surface needs, pain points, and the workflow gaps the tool was not covering, and turned that qualitative input into a prioritized backlog. Sitting close to both Sales Operations and the reps doing the selling kept the work grounded in the real job, not an idealized one.
Frontline reps
My primary users. They showed me where the tool added clicks, where they fell back to spreadsheets, and what a good day actually looked like.
Sales Operations
The owners of data quality and reporting. They framed which gaps hurt downstream visibility and where bad data started.
Engineering
My build partner. We sized feasibility together so prioritization was honest about effort, not just demand.
Product (me)
I translated pain points into requirements, set priority against impact and effort, and owned the call on what shipped.
Discover
recurring Sales sessions
Synthesize
pain points to themes
Prioritize
impact vs. effort
Deliver
build with engineering
Adopt
roll out & reinforce
Improvements that matched the tool to the work
The backlog turned into a set of focused improvements. Each one came from a named pain point in discovery and was sized with engineering before it shipped.
Workflow simplification
Reshaped the highest-frequency rep flows so common tasks took fewer steps and fewer screens, removing the dead ends that pushed people to side spreadsheets.
Data & field quality
Rationalized the fields reps actually used, tightened inputs, and reduced redundant entry, so the data captured once stayed trustworthy downstream for Sales Operations.
Reporting & visibility
Gave Sales clearer, more self-serve views of their own pipeline and activity, so answering "where do things stand?" stopped requiring a manual pull.
Usability
Smoothed the everyday surfaces, clearer labels, saner defaults, less friction, so the tool felt built for the seller rather than for the system underneath it.
Balancing what Sales wanted against what would land
IllustrativeSales always wants more than one team can build, and the loudest request is not always the highest-impact one. I scored requests against the pain they relieved and the effort to ship, then made an explicit Build, Defer, or Decline call, so I could say yes with conviction and no with a reason. The pattern below is representative of how I weighed it.
| Request from Sales | Impact | Effort | Call |
|---|---|---|---|
| Streamline the highest-frequency daily flow | High | Med | Build |
| Clean up fields driving bad downstream data | High | Low | Build |
| Heavily custom view for a single use case | Med | High | Defer |
| Net-new module overlapping a planned migration | Low | High | Decline |
The trade-off: I led with the high-impact, low-to-medium-effort fixes that helped the most reps fastest, deferred bespoke one-off requests, and declined work that a known future direction would soon make redundant. Saying no to a few loud asks is what protected the throughput that earned Sales' trust.
The shift, from worked-around to relied-on
Before
Reps worked around the CRM with manual steps and side spreadsheets, Sales Ops reconciled data by hand, and basic "where do we stand?" answers needed a manual pull.
After
The tool fit the daily flow, common tasks took fewer steps, the data captured once stayed trustworthy, and Sales could self-serve a clear view of their own pipeline.
Adoption
~90% of reps active
Time saved
~4 hrs/week per rep
Efficiency
6 fewer clicks per task
Satisfaction
High among reps
What building for an internal sales org taught me
Your users are a captive audience, so earn it anyway
Internal users cannot churn, but they can route around you. Adoption, not a mandate, is the only honest signal that the tool actually fits the work.
Sit with the seller, not just the spreadsheet
Recurring time with frontline reps surfaced friction that no ticket queue would have. The workaround is the requirement, written in the user's own hand.
Protect throughput with a clear no
Saying no to bespoke or soon-to-be-redundant asks, with a reason, is what kept the high-impact fixes moving and kept Sales' trust intact.