6 ms·

> Objective – Increase Customer Retention > Key Result #1 – Lifetime Customer value increase from $N to $N+5 > Key Result #2 – Decrease Customer Churn Rate by

• maxxxxx 7y ago
  That’s a huge problem with the whole idea of providing value to the business. Some people can show real metrics but a lot of us are several layers away from anything quantifiable so either you have nothing to show or you have to make up some bullshit metric as I often see in resumes.
  • avip 7y ago
    Slightly off, but the whole "business value" in IT resumes is proper a US thing. Cross the border and you're good with just mentioning what you did, sans the (often imaginary) "impact".
• nlawalker 7y ago
  Yeah, this wasn't at all what I thought it would be about, which is the difficulty (impossibility?) of measuring developer impact against key results. When you're a salesperson, you don't have to agonize over how to illustrate that you've "Decreased Customer Churn Rate by 10%". When you're an assembly line worker, you don't have to find a way to figure out how you contributed to "produce 15% more widgets". You either accomplish these things or you don't - they are literally descriptions of your performance in your job. Either way, nobody cares how you did (or didn't) do it. When you're a developer, how are you supposed to show that you've helped "increase customer value from $N to $N+5"? Because "shipped the new version of the message queuing system" is not in anyone's list of key results. OKRs feel like "organized SMART goals", and so I have the same criticism of them as I do of SMART goals: they're just another way of conceptualizing goals around things that are already easily and directly measured. No one has made any progress in quantifying the contributions of roles that don't have direct percentage impacts on dollars earned or dollars saved.
  • gipp 7y ago
    If that's what your OKRs look like as a developer, then your company is doing them very wrong. They're supposed to be hierarchical, becoming more concrete as you go down the line. Your examples sound like top-level OKRs; mine are usually something like "internationalize feature x, launch in Y locales" or "Implement feature Z, measure effect on meric A". Which is not to say the OKR system doesn't still have issues, they just look more like the ones discussed in the OP.
    • thinksocrates 7y ago
      Yeah, if that's how it supposed to work, then I've not been anywhere that does it right. We're always working ones like what I mentioned in the post.
      • sanderjd 7y ago
        Yep, this would be good feedback up the chain. People above you should be working on breaking the company level goals into team and role specific ones. Edit: just to note that I have some other criticisms of OKRs, but having them be way too high level, broad, and not actionable should not be the problem.
        • cstrasen 7y ago
          Please share your criticism. I would be happy to get as much perspective on the topic as possible. The problem I encountered was having, or the notion of wanting, a product roadmap which is produced from stakeholder, C-level, product- and IT team input parallel to OKRs. I feel this is an anti pattern. You have OKRs and they make your quarterly roadmap or you don't apply OKRs at all to the producing team.
    • nlawalker 7y ago
      That would be nice. My intuition is that this doesn't happen because the person in the hierarchy who translates "improve customer value by x%" into "internationalize feature x, launch in Y locales" is effectively taking responsibility for showing that the latter impacts the former, which is the problem I find to be intractable.
• hirundo 7y ago
  > How am I supposed to know why customers are churning? I'm three levels removed from talking to customers when they cancel. I don't have a deep relationship to know how to add value to them. Most design decisions you make as a developer affect the value users get from your product, and therefore the churn rate. Sure you can get more useful data by talking to customers, and you should seek it out. But even lacking that, it's up to you to put yourself in the place of a user and make the most practical decisions available for their benefit that your powers of intuition allow. You don't get to say, I don't have the best possible data for that choice therefore it's not my problem. It's still your problem.
  • swanson 7y ago
    It's the right attitude in spirit. But like how am I supposed to know how to decrease no-show rates at a clinic? How can I figure out how to increase harvest yields from autonomous tractors? Convert more enterprise sales accounts? I know that the answer is: spend lots of time talking to customers, doing research, empathizing, etc. But then who is going to write the code while I'm doing all of that? It needs to get done, but I'm not sure why that is the job of the "development team".
    • Jtsummers 7y ago
      One thing with OKRs is that the key results are supposed to be in your control and responsibility. You don't have control over the no-show rate, but someone has responsibility to improve that as part of their own role. If that has made it to your team, then something is probably broken. Most likely that no-show rate is part of an OKR for clinic managers or someone else. They'll come up with ideas (or consult with you for ideas) and your team is responsible for implementing the improvement or running experiments to see if it actually achieves the desired improvement. That means your OKR will have to do with responsiveness to your customer or addressing the things your customer believes are associated with the poor no-show rate. Is your "patient reminder" system broken and failing to contact patients? Do you lack such a system? That's something you can address and control, so the OKR will have to do with that (server uptime, quality of service, features of the service, timeliness of changes to the service).
• superfrank 7y ago
  > I'm a developer on a team. How am I supposed to know why customers are churning? I'm three levels removed from talking to customers when they cancel. I don't have a deep relationship to know how to add value to them. I hope no one is expecting every individual developer to know the numbers on churn, but I do think it's important that someone on the eng team would know that number. In my experience, some combination of the product manager and the tech lead for the team should have some insight into how the changes the engineers are making affects the customer.
  • edmundsauto 7y ago
    If churn is a priority from leadership (and it should be, for any decent sized product), I would expect everyone to understand the factors that play in. You need all your engineers to understand the strategic goals, they are often the best positioned to suggest ideas for fixing them (or can prioritize fixes that are higher impact to priority areas).
    • hobs 7y ago
      And then you have to do the hard thing, which is listen to the engineers (which is why most business folks are fine with keeping the siloing as is.)
      • MrDunham 7y ago
        I love listening to my engineers. They usually know how to solve something faster and more elegantly then I do. But I'm someone who will learn enough Node/React/python to understand what can, and can't, be done.
      • BurningFrog 7y ago
        A lot of engineers talk about how business people should listen to engineers. A lot fewer engineers talk about how they like to listen to business people.
        • hobs 7y ago
• lifeisstillgood 7y ago
  I believe it should work like this - Board to CTO : Increase Retention (decrease churn) - CTO to DevLeads: * Build a daily report emailed to the board showing 30 day moving average of churn * Build a business event log - every time a user does something on the system log it to a easily queryable system (customer signs in, customer raises invoice or customer deletes widget) This can get very deep very fast. Start with Graphite / carbon and get more sophisticated later. * hire a data scientist / convert DBA into one and find correlations between customers who churn and events in the log. Not logged in for 30 days looks like a good start. * Write split testing into the (SaaS) app such that we can randomly segment customers at risk of churning (indicates by event activity) and see if we can keep them * also add in "have you tried this feature emails", or "holy crap what do you mean the invoice page does not align right anymore" All of these things (for a SaaS app) are doable projects for any development team. This is of course based on the idea that the Board has told the CTO "fix this thing as top priority". If they have not that's their problem. The CTO should then go to the board and say "I am going to fix this thing as top priority" Then we start the fun job of actually monitoring what developers do work on compared to what we planned to work on. Most times priorities chnage, legacy weighs us down and friction burns is.
  • smackay 7y ago
    Or you could just fix all the bugs that are upsetting customers and causing them to flee. I've been in the situation where the metrics were used at a detailed level. Net Promotor Score (NPS) was used by the company and I tried, somewhat successfully, somewhat unsuccessfully to use OKRs at the team level. I agree with everything that has been said in using these to set the overall the direction and strategy at a high/medium level but down on the front lines it's very hard to do anything that will move the needle in the right direction in a clear cause and effect way. If you try and map tasks to strategic goal then you just up window-dressing everything to keep management happy and since the components of goal X are many any varied your chances of success are limited.
    • josho 7y ago
      > If you try and map tasks to strategic goal then you just up window-dressing everything If you don't understand how your daily work is related to management's priorities then probability is high that you are going to do a lot of work that isn't valuable to the organization. So, either it should be a trivial exercise to rationalize how a task is related to the objective, in which case this is nothing more than a small overhead of working in an organization. Or if you find you have to make leaps of faith to make the connection to the objective then that's a signal that you need to consider why the task needs to be done at all.
• deleted 7y ago
  [deleted]
• bluGill 7y ago
  If you are a good developer you understand the customer a little. You are the first line of defense against things that seemed like a good idea, until they are implemented. You should pay attention to what you are building, once in a while (not every developer will have this happen) you will see something and go to your boss with a "stop, look at this, it we should cut our losses now because it is bad for the metrics". You as an engineer know what is possible. I've seen several projects go from ideas that management/marketing thinks are too difficult so they don't bring it up to the top must have feature when an engineer who understands the customer sits down and writes it in a couple days thus making them realize their idea was actually easy if only they had asked.
• leggomylibro 7y ago
  I once worked somewhere that had in-house customer service, and they gave developers the opportunity to spend a couple of days every few months working with a representative to respond to tickets and other first-line support stuff. It was very valuable. It turns out that listening to people is a good way to figure out what they are frustrated with and what they want to see. Who'da guessed?
• pbreit 7y ago
  I think OKRs are intended to mitigate the lack of customer awareness exhibited in this post. If you’re having that hard of a time linking your efforts to your paying customers, that sounds like a problem.
• yawz 7y ago
  Aside from transparency and common goal, the most beneficial side of OKRs is to allow any individual to ask "does what I'm currently doing move us closer to the KRs?" and "is this the most important thing that I can do to contribute to the KRs?"
• devit 7y ago
  Also what's the point of arbitrary numbers like "10%" and "+5"? You should obviously increase lifetime customer value to the optimal value (after accounting the cost of increasing it) and likewise for churn rate.
• ken 7y ago
  > How am I supposed to know why customers are churning? I'm three levels removed from talking to customers when they cancel. I'm always amused by where one job ends and another begins. It seems strange to me that every web software company in the world is looking for "full stack engineers" -- you need to be an expert at everything from CPU instructions up to the CSS3 color module and its implementation in the browsers that our users are using -- but doing research and analysis of user behavior is off-limits. That's where we're drawing the line?
  • robryan 7y ago
    It comes down to allocating resources. If your developers are tasked with doing research on churn what are your product/ customer success people doing? Obviously depends on the size of the team on the product.
  • ared38 7y ago
    Because we're too expensive to waste on something another employee could do. The bitter irony is we're so expensive largely because being siloed leads to wasted effort and rework.
• strogonoff 7y ago
  “I'm a developer on a team. How am I supposed to know why customers are churning?” OKRs are designed to exist in levels, “trickling down” in a way that narrows them down more and more as they reach specific teams and individuals[0]. A goal such as “Increase customer retention” could be a legitimate higher-level objective. From key results on that objective, we get objectives for specific teams working on various aspects of the product. (For example, “Reduce churn rate by X” likely isn’t going to be just about engineering; copywriters and others may be involved. Down the line at some point there may be an engineer’s personal key result such as “launch customer feedback collection system by X date”, or something else specific to circumstances.) I believe that wholeheartedly adopting OKRs in this multi-level fashion is helpful even to companies with a just a few employees, and how objectives and results are translated across levels is a good measure of management health overall. [0] Rick Klau talks about it in “How Google set goals” https://youtu.be/mJB83EZtAjc?t=1951 https://youtu.be/mJB83EZtAjc?t=1951 (2013)
  • jwilliams 7y ago
    To be honest, I've rarely seen this work well outside of Google. Part of it is how the goals are translated. A business outcome trickles down to a specific technical one -- and a specific team and person -- which on the face of it makes sense, but it's surprising how often pursing that that derived outcome totally loses sight of the big picture. It's similarly hard to map backwards, which can lead to a lot of the company feeling "mission accomplished", when the objective was still a total miss. That's a painful disconnect to have happen.
• jcrites 7y ago
  > I'm a developer on a team. How am I supposed to know why customers are churning? One approach is to keep in touch with customers and find out what their pain points are. Everyone should be interacting with customers to some extent. This could entail helping out with some support requests (escalations), or joining customer calls, going to conferences, etc. Listen silently to sales calls, or support calls with important customers - or be a named and introduced participant. If you have a mailing list or forums, keep tabs on that and help people. You can usually get an intuitive sense of what’s important to customers by interacting with them. Sure, maybe it’s “not your job” to do these things, but a bit of time spent more than pays off in insight most of the time. If this is difficult to arrange, then the next best thing is to talk to the people who themselves speak to customers, and listen to what they have to say. This isn’t a replacement for surveys and analysis, but I find it useful to have my own intuition as a human based on interacting with other humans. It’s also good to be a customer or user of your own product. I strive to be in the position to use the things that I’m working on first-hand myself. If your product has an involved onboarding or setup process, then ideally everyone on the team should have gone through that setup themselves personally. Most of the product design vision that I’ve developed for products I’ve worked on has come from a studied understanding of the customer problem and interaction with real customers. I think the best way to stay customer-obsessed is to ensure you’re interacting with customers, or are one yourself.
• taboca 7y ago
  Inspired by * I will elaborate a bit on what I think would be an OKR-approach for that. It could be a goal like "How am I supposed to know why customers are churning?". Then your key results would be, not the metric that says "Working on that", but the metric that helps you with answering the question in a way that proves or solves the puzzle ideally. There are many things that are solvable and for these the OKR recommends "Committed OKRs" while for things that are unclear there is the "aspirational OKRs". Say, for the above: KR A being test the hypothesis for churning using XYZ analysis method and KR B bring peer review that with specialist named Klopvital, Tartirius and Mochalatet. Then, once you improved an answer, I would think you have achieved a partial goal - and if that is data to someone else then it comes the choreography of things. . . . The whole reason of a system of goals is to have one work and what OKR helps relates to accountability - what is a measure that validates the goal. Of course, the complexity comes when one goal system is chained with the other - the orchestration. Your case "Someone needs to do the research, analysis, and leg work of finding potential areas to exploit." partially opens the door to it for the idea of Committed OKR (the kind of OKRs that one can do, solvable). On your point "And then someone needs to have at least some amount of vision or inspiration about how to solve that problem." this seems to be about the idea of Aspirational OKR. In this regard, I agree that many things in the entrepreneurial outset starts with a north and not a precise thing. Certainly OKR is not a system to work on requirements - do it and that is that. The OKR approach is influenced by short feedback reviews for goals — that is derived or inspired by Andy Grove insights about MBO vs feedback vs planning that goes on like a) point to a roadmap b) work on it with a temporary plan in an accountable transparent way c) review the plan and review the roadmap. But I hear your strong statement that "but the last time I worked in an environment with OKR no one seemed to have any brilliant ideas about how to, you know, actually achieve the Key Results." and would love to talk with you to understand more your experience. From the book I read I came upon cases that some of the success cases too years to fix their OKR system. * Some of the ideas here I was inspired by the Measure What Matters book by John Doerr. But of course it's my limited interpretation.