when you “build something people want,” the truth is a lot of people still don’t want it. they may pay for it, but really they pay you to change it. sometimes endlessly.
this meme i just created explains the vicious cycle:
and i’m getting sick of it. maybe i’m just old. or maybe i’m finally disillusioned with startups and scrum and so-called rapid development. enough that i’m going to do something about it.
so if you write code or manage product teams, i’d appreciate your $0.02 on my approach to this challenge at an engineering organization i just inherited.
(oh and by the way, in this post i’m referring only to competitive products that must iterate in order to exist. i am ignoring masterpieces like Craigslist)
background
i began working in tech in 2012 as a marketer, later transitioning to product and eventually development by 2017.
over the last 12 years i’ve personally built and deployed dozens of products, or founded and managed teams who shipped millions of lines of code touched by 100s of millions of people.
today
at my Day Job we recently acquired a SaaS product with 43,000 active accounts and upwards of 1,600 support tickets per week. there are 5 full time engineers and 2 support engineers who spend most of their time reacting to these tickets.
now this isn’t all bad. some tickets catch obscure bugs that might affect other accounts later. and some tickets lean more on education, solvable with improvements to our support guides.
where things get hairy are tickets like these:
- “it would be great if you did X too, i need it or else i’ll cancel” (something nobody has requested)
- “feature Y should be more like Z” (despite no previous confusion)
- “this doesn’t work with my [2007 web browser | already-broken website | emotional state]“
again, there are many ticket categories with best practices in place. for example, if someone requests a niche feature you can ask them to upgrade their plan or pay a flat fee. if someone requests an integration with X product, you can offer a DIY approach that combines solutions like Zapier or webhooks.
but what about when someone already pays a lot of money and threatens cancelation? do you drop everything and oblige, or ignore and hope for the best? is the customer nuts, or will their insights help you break through to a new market altogether?
the only way to address these challenges is with good judgment.
to grow our latest acquisition, below is my current working application of judgment from 12 years in the startup ecosystem. i’m outlining 4 different approaches i considered before making a final decision.
Strategy A – status quo
summary: react to tickets with gut instincts. squeaky wheel (upset customer) gets the grease (expedited patch). backlog requests that seem low priority. occasionally prioritize miscellaneous items when other projects are paused, or when bored.
note: this is the system i inherited, and frankly the system i grew to be part of at other startups. it is the natural progression of product roadmaps… they only get bigger, despite the velocity of cards being moved to Done.
pros: intuitive; basically an 80/20 approach to making progress
cons: frequent little fires/emergencies; difficult to determine which % of engineering effort is wasted
Strategy B – better “priority” calculation
summary: require more checks and balances by the support or product team before requests are assigned to engineers. achieved with new hierarchy rules on your kanban or ticketing system to yield fewer tasks on the active roadmap.
note: we considered tweaking our Support -> Engineering pipeline by adding barriers like “must require $N+ in affected monthly revenue” or “must be an at-risk customer” (50% chance of cancelation). but these thresholds are non-trivial to calculate, putting us back at Status A (individual gut instincts).
pros: easy to communicate with customers – only users on XYZ plan get customizations, sorry
cons: short-sighted as special requests often beget upgrades/loyalty; exploitable by team and users (universal rule of ASAP – shortly after a magical term is introduced, every memo says “ASAP”)
Strategy C – task “credit” system
summary: every N period allocate front lines team members some assignment credits. could be literal (engineering hours) or aligned with your task management system (t-shirt size, etc).
note: at our new company, each support engineer already compiles a “top 5 customer requests” before each standup meeting. initially this seemed like a natural way to prioritize tasks. however it still leans heavily on support engineers’ gut instincts. this system could accidentally bury great ideas.
pros: calmer internal operations; some noise reduction (net fewer requests)
cons: difficult to rationalize to customers (a la politics, users will lobby for their request to be chosen as they don’t care or know about big picture company goals)
Strategy D – half time
summary: engineers spend half their time on the usual stuff — pet feature requests and small bug fixes. then spend the other half of their week on internal initiatives, larger features, long term improvements.
note: the organization we recently took over had nearly 400 items on the backlog. last month we reduced it to 236 tasks, but completing them would still take 1-2 years even if every other incoming request was deleted.
pros: easy to implement or reverse-implement; reduces context switching for engineers; steady cadence of forward motion on important (not urgent) projects
cons: requires more blocking/tackling by customer-facing team members to keep users patiently waiting; more difficult to estimate completion timelines internally or externally
and the winner is…
i have a policy of empowering team members to act like [and eventually become] owners. i do this through equity, bonuses, investing in their side projects, paying for outside learning, etc.
so we’re trying Strategy D.
in my opinion this aligns most closely with being an owner, which is really just a neverending battle of making time to work “in” the business instead of working “on” the business, aka reversion to the mean.
the second closest strategy to encouraging ownership is the credit system, but i’m concerned that customer drama (nagging feature request buildup) would outweigh the benefits of agency in “spending” engineering resources. further, managing constrained resources is the Boss’ problem. i am not trying to delegate my responsibilities here, just move faster.
so we’ll see how this works out. but i’m curious, what do you think?