11 ms·

Talking to your customers: a disruptive Agile framework

112 points by lucasfcosta 4y ago

kriro 4y ago
For managers who think this might not be easy to put into use, don't worry. TTYC already has all the fancy Agile branding and speak under the "user centered desing" umbrella including expensive workshops and even an ISO standard (9241-210:2019). ;)
WantonQuantum 4y ago
Pro tip: If you're planning to build a product, you might need to find your customers first. Then follow the TTYC process.
- yomkippur 4y ago
  It's actually the other way around I found but yeah important to know where the customers are first and how to reach them. If you want to find a customer, you need to have a product in my experience. Very few outside of US are willing to risk take.
  - Nowado 4y ago
    They likely don't mean 'customer' in the sense of a paying one, but a person with a need you can fulfil and resources to compensate you with. It's sort of potential, not yet actualized aspect of a 'customer' as a piece of a 'person', that would become 'real' in a presence of your product.
    - WantonQuantum 4y ago
      Yep, that's what I meant.
amitgupta6 4y ago
Extending this further. Before building a product, talk to prospects and understand the problem better.
xcambar 4y ago
Yes but talking is enifficient and a waste of my velocity. I'd rather ship it (tm) and analyze the conversion funnels by cohort with A/B. Cause that's what growth hacking gurus tell me on YouTube . /s (hopefully that was obvious to all)
- YouWhy 4y ago
  The narrative minus the irony sure sounds a lot like what one of the adtech giants was doing. Might have been the cause of them having lost circa 50% of market cap when the chicken came to roost.
allenleee 4y ago
I believe this approach will lead you to very incremental solutions. It lowers the cost of failure (downside), but also the potential impact of success (upside). This approach determines your mindset as a product designer and destroys your potential product/business upside upfront. Most users get pitched "understandable ideas" because builders think they have to prove market fit before building product depth. The most successful companies don't discover markets, they create them. Most visionaries forge the macro (10x) jump and then ask customers for the micro improvements. The meaningful, big-leap innovations are often not obvious from the start: If you're creating something that will be a great company 10 years from now, most people will probably not get it at first.
- buscoquadnary 4y ago
  That's the exact idea behind Agile. Sure it may limit some impact of success, but I bet you way more people are blowing millions of dollars trying to pull big products out of their hat. And for the record the number of "visionaries" is incredibly small, and pretty much everyone I've ever met that considered themselves a "visionary" is a con artist that talks a good game, has the technical acumen of day old mayonnaise and excuses being a colossal a-hole because Steve Jobs did it that way. EDIT: Further I am realizing your talk about creating markets isn't so true either. Google, Microsoft, Amazon, none of these companies were really visionary, and they are the biggest names around.
  - JohnFen 4y ago
    The pioneers get all the arrows. If your goal is to maximize profit and marketshare, you don't want to be the first to do a thing. You want to be the second or third. That's where the money is. Being a pioneer, though, is far more enjoyable.
- RandomLensman 4y ago
  To be fair, a lot of software development is for inhouse, sometimes specialized, things. The tech side being the visionary there is potentially quite difficult without specialized knowledge (e.g., via some hybrid roles as seen in some industries).
skybrian 4y ago
Somehow the customer will be replaced with a customer proxy who pretends to know what the customer wants.
- bitwize 4y ago
  I take the requirements from the customers and I bring them to the engineers! What the hell is wrong with you people?!
lukasfischer 4y ago
I had to smile the whole article while reading.
teucris 4y ago
I’ve been whining about the constant agile-bashing for a while…I understand that implementing agile often leads to the MSDM model (many small death marches) but I never quite got the loathing agile gets from the tech community. I think this gives me a glimpse. To me, agile is about adjusting your planning so you can get customer feedback and adjust your project accordingly. Without that, much of what I value from agile goes out the window.
- nickmyersdt 4y ago
  Agile works when everything in your business aligns with it as a way of working. It fails (and therefore is loathed) when the people who need time, focus, room, safety to achieve the outcomes are forced into working with particular processes, procedures or tools in order to satisfy someone other than the team or the customer.
- Arcanum-XIII 4y ago
  The main problems I’ve seen are: - followed as a religion, especially when it doesn’t make sense (daily stand up for a team working in the same room and collaborating all day long? One day lost every 2 week for planning and review? Trying to do a stand up with too many people?) - using it as an excuse to not prepare the project and without clear objective - trying to fit agile in a fixed schedule (like trying to sync with a big marketing release, complete with pre reserved tv spot 1 year in advance) - not listening to the final customer - heck, not even making sure he’s interested - trying to complexity it by adding a lot of metrics (financial is a big one) - making estimate as the law
  - agos 4y ago
    I don't want to say "no true scotsman", but agile has no requirements on stand ups, schedules, or estimates.
    - pydry 4y ago
      Agile has always been extremely vague about what it is. This is at the heart of the problem. This allows everyone to project their own desires on to it - from CEO to PM to programmer to consultant. I get why this happened - the original consultants probably felt that defining it in a way that would alienate people (especially leaders with the budget to hire them) wouldnt be good business. Nonetheless it led to all this. Scrum was almost worse - an attempt to be specific and regimented about process without being alienating which is how I ended up working on a project for BigBank where they asked for N story points to be delivered per month in the contract. Ideally Id like to see some new sort of movement X that follows the heart of what agile is and isnt afraid to get specific in a way that would alienate a CEO/pm with waterfall/controlling tendencies. This way I could ask in a job interview if the companies does X or agile and get a clearer answer about wtf they do.
brutuz 4y ago
Talking is cheap and could be very misleading if your customer/user haven't put their skin into the game.
- satyrnein 4y ago
  Learned this one the hard way. If you ask the equivalent of "what could I add to make this more useful?" you will get a lot of worthless suggestions like "I don't know, maybe make it sortable by the other column, too?" that don't move the needle at all on engagement.
  - Jwarder 4y ago
    As has been said before: Users are almost always right when they say a problem exists; but they are almost always wrong when they suggest a solution.
- outsidetheparty 4y ago
  I think the point is more that _not_ talking is even more misleading.
juunge 4y ago
I was very surprised about the "talk to your customers" part
usrusr 4y ago
Seems to rest on the assumption that customers want to. But in my experience, quite often the unspoken goals include not only "cheap" and "finished yesterday", but also "without bothering me outside of a fancy kickoff and that penultimate mission accomplished meeting where I bikeshed off through all the shades of blue" That desire can still only be served by its opposite, talking to the customer, but it's a scarce resource, not just something you don't use enough of. Similar to how "finished yesterday" can only be solved by more time, but that can't be time measured in decades.
withinboredom 4y ago
I have brought up talking, like picking up the phone and saying hi, at every workplace I have ever been. The response has always been hilarious, after they also think it is “such a great idea.” - we have sales for that - we should see if we can get a special team for this - let’s just email everyone a survey From my personal Azure account, Microsoft has called me a handful of times, with a product manager and engineer on the call, just to ask about some random feature I’ve used recently. (Who I stole the idea from, btw) Every single time, I’ve learned something that I didn’t know to look for, and they learned what my usecase was, my hardships, etc. It was a good experience for both parties. It may take awhile, but seeing some of the issues you had be resolved is also satisfying as a customer. I’ve built small products, worked for startups etc. I get the feeling that most devs are terrified to actually talk to the customers they build for. I’m not, because of my background, but most devs don’t have that background.
- citizenkeen 4y ago
  So you’re the reason Azure’s interface is constantly in flux.
- jrib 4y ago
  I've had Atlassian's bitbucket team reach out to me after I expressed frustration in a survey. It was a manager and a developer on the call. They listened intently. I think the call lasted at least 30 minutes. I think bitbucket improved a lot over the last few years. I like to think that practice of talking with users was a significant part of that.
- tchock23 4y ago
  Andrew Mason reached out to me to do an interview about his new startup Descript. Dude is worth a lot of money from his Groupon days and here he is doing one on one calls with his customers. I think it’s a big reason why Descript is a great product. Even if he isn’t the one doing that forever, it sets a huge cultural expectation that listening to customers matters.
- cpursley 4y ago
  Did they (Azure) schedule the call or randomly dial you up? I'm trying to figure out how to do this with our customers without disrupting them (their workflow, day). And for busy customers, it seems like maybe these types of calls are not high priority enough (vs "app is down" situations) to get them to schedule. I will say, customer development (prospects) are helpful. I've learned so much about what to and not to spend time building. I'd like to get the same milage out if existing customers.
mkl95 4y ago
I used to do this when I was leading the development of an internal tool used by a small research department. Researchers were initially using a clunky prototype that had not received any end user feedback. By meeting them regularly I was able to fix their pet peeves, add the features they needed, and remove useless stuff. Doing this for an internal tool is of course relatively easy, but ever since I have been wondering if it would work for B2B software.
- Lutger 4y ago
  Yes it works, and it works really well in my experience, but only if the context is right. The trick is you need to get the real end users on board at least, in addition to and alignment with the one who is calling the shots and/or owning the budget. Most of the time in business, the person making the decisions is not the one who has to live with the consequences. So for B2B the ability of the decision makers to do sensible things is your limiting factor. You need to really partner up with the decision maker(s), and get a feel for whose problems you are actually solving. Sometimes there's this political layer over the actual problems that is making things more complex, and which is not actually explicit. Not understanding this layer can lead to a lot of frustration in my experience.
shsbdncudx 4y ago
Listen to your customer. Agile is fine, but the product it’s become is an abomination. It’s about reducing the cost of learning. That’s it.
whoevercares 4y ago
This is a quite ok framework for greenfield project in Big Tech IMO, where we have this exact problem - debating the strategy from Q1-Q3 and starting coding in Sept and deliver craps
BasilPH 4y ago
"The Mom Test"[^0] is an excellent and short book about how to conduct those talks that I can highly recommend. It teaches you how to truly listen, and not bias the person you're interviewing. Two points that stuck with me: - Humans are bad at estimating, so make your questions very concrete. Don't ask "How often do you look up recipes on your iPad", but rather "How often did you use your iPad for recipes last week?". - Nobody likes telling somebody else that their baby is ugly. Show the prototypes at the end of the interview, once you learned everything about the problem they had to tell you. If you show them your solution too early, you'll bias them. [^0]: https://www.momtestbook.com https://www.momtestbook.com

112 points by lucasfcosta 4y ago

For managers who think this might not be easy to put into use, don't worry. TTYC already has all the fancy Agile branding and speak under the "user centered desing" umbrella including expensive workshops and even an ISO standard (9241-210:2019). ;)

WantonQuantum 4y ago

Pro tip: If you're planning to build a product, you might need to find your customers first. Then follow the TTYC process.

yomkippur 4y ago
It's actually the other way around I found but yeah important to know where the customers are first and how to reach them. If you want to find a customer, you need to have a product in my experience. Very few outside of US are willing to risk take.
- Nowado 4y ago
  They likely don't mean 'customer' in the sense of a paying one, but a person with a need you can fulfil and resources to compensate you with. It's sort of potential, not yet actualized aspect of a 'customer' as a piece of a 'person', that would become 'real' in a presence of your product.
  - WantonQuantum 4y ago
    Yep, that's what I meant.

amitgupta6 4y ago

Extending this further. Before building a product, talk to prospects and understand the problem better.

xcambar 4y ago

Yes but talking is enifficient and a waste of my velocity. I'd rather ship it (tm) and analyze the conversion funnels by cohort with A/B. Cause that's what growth hacking gurus tell me on YouTube . /s (hopefully that was obvious to all)

YouWhy 4y ago
The narrative minus the irony sure sounds a lot like what one of the adtech giants was doing. Might have been the cause of them having lost circa 50% of market cap when the chicken came to roost.

allenleee 4y ago

I believe this approach will lead you to very incremental solutions. It lowers the cost of failure (downside), but also the potential impact of success (upside). This approach determines your mindset as a product designer and destroys your potential product/business upside upfront. Most users get pitched "understandable ideas" because builders think they have to prove market fit before building product depth. The most successful companies don't discover markets, they create them. Most visionaries forge the macro (10x) jump and then ask customers for the micro improvements. The meaningful, big-leap innovations are often not obvious from the start: If you're creating something that will be a great company 10 years from now, most people will probably not get it at first.

buscoquadnary 4y ago
That's the exact idea behind Agile. Sure it may limit some impact of success, but I bet you way more people are blowing millions of dollars trying to pull big products out of their hat. And for the record the number of "visionaries" is incredibly small, and pretty much everyone I've ever met that considered themselves a "visionary" is a con artist that talks a good game, has the technical acumen of day old mayonnaise and excuses being a colossal a-hole because Steve Jobs did it that way. EDIT: Further I am realizing your talk about creating markets isn't so true either. Google, Microsoft, Amazon, none of these companies were really visionary, and they are the biggest names around.
- JohnFen 4y ago
  The pioneers get all the arrows. If your goal is to maximize profit and marketshare, you don't want to be the first to do a thing. You want to be the second or third. That's where the money is. Being a pioneer, though, is far more enjoyable.
RandomLensman 4y ago
To be fair, a lot of software development is for inhouse, sometimes specialized, things. The tech side being the visionary there is potentially quite difficult without specialized knowledge (e.g., via some hybrid roles as seen in some industries).

skybrian 4y ago

Somehow the customer will be replaced with a customer proxy who pretends to know what the customer wants.

bitwize 4y ago
I take the requirements from the customers and I bring them to the engineers! What the hell is wrong with you people?!

lukasfischer 4y ago

I had to smile the whole article while reading.

teucris 4y ago

I’ve been whining about the constant agile-bashing for a while…I understand that implementing agile often leads to the MSDM model (many small death marches) but I never quite got the loathing agile gets from the tech community. I think this gives me a glimpse. To me, agile is about adjusting your planning so you can get customer feedback and adjust your project accordingly. Without that, much of what I value from agile goes out the window.

nickmyersdt 4y ago
Agile works when everything in your business aligns with it as a way of working. It fails (and therefore is loathed) when the people who need time, focus, room, safety to achieve the outcomes are forced into working with particular processes, procedures or tools in order to satisfy someone other than the team or the customer.
Arcanum-XIII 4y ago
The main problems I’ve seen are: - followed as a religion, especially when it doesn’t make sense (daily stand up for a team working in the same room and collaborating all day long? One day lost every 2 week for planning and review? Trying to do a stand up with too many people?) - using it as an excuse to not prepare the project and without clear objective - trying to fit agile in a fixed schedule (like trying to sync with a big marketing release, complete with pre reserved tv spot 1 year in advance) - not listening to the final customer - heck, not even making sure he’s interested - trying to complexity it by adding a lot of metrics (financial is a big one) - making estimate as the law
- agos 4y ago
  I don't want to say "no true scotsman", but agile has no requirements on stand ups, schedules, or estimates.
  - pydry 4y ago
    Agile has always been extremely vague about what it is. This is at the heart of the problem. This allows everyone to project their own desires on to it - from CEO to PM to programmer to consultant. I get why this happened - the original consultants probably felt that defining it in a way that would alienate people (especially leaders with the budget to hire them) wouldnt be good business. Nonetheless it led to all this. Scrum was almost worse - an attempt to be specific and regimented about process without being alienating which is how I ended up working on a project for BigBank where they asked for N story points to be delivered per month in the contract. Ideally Id like to see some new sort of movement X that follows the heart of what agile is and isnt afraid to get specific in a way that would alienate a CEO/pm with waterfall/controlling tendencies. This way I could ask in a job interview if the companies does X or agile and get a clearer answer about wtf they do.

brutuz 4y ago

Talking is cheap and could be very misleading if your customer/user haven't put their skin into the game.

satyrnein 4y ago
Learned this one the hard way. If you ask the equivalent of "what could I add to make this more useful?" you will get a lot of worthless suggestions like "I don't know, maybe make it sortable by the other column, too?" that don't move the needle at all on engagement.
- Jwarder 4y ago
  As has been said before: Users are almost always right when they say a problem exists; but they are almost always wrong when they suggest a solution.
outsidetheparty 4y ago
I think the point is more that _not_ talking is even more misleading.

juunge 4y ago

I was very surprised about the "talk to your customers" part

usrusr 4y ago

Seems to rest on the assumption that customers want to. But in my experience, quite often the unspoken goals include not only "cheap" and "finished yesterday", but also "without bothering me outside of a fancy kickoff and that penultimate mission accomplished meeting where I bikeshed off through all the shades of blue" That desire can still only be served by its opposite, talking to the customer, but it's a scarce resource, not just something you don't use enough of. Similar to how "finished yesterday" can only be solved by more time, but that can't be time measured in decades.

withinboredom 4y ago

I have brought up talking, like picking up the phone and saying hi, at every workplace I have ever been. The response has always been hilarious, after they also think it is “such a great idea.” - we have sales for that - we should see if we can get a special team for this - let’s just email everyone a survey From my personal Azure account, Microsoft has called me a handful of times, with a product manager and engineer on the call, just to ask about some random feature I’ve used recently. (Who I stole the idea from, btw) Every single time, I’ve learned something that I didn’t know to look for, and they learned what my usecase was, my hardships, etc. It was a good experience for both parties. It may take awhile, but seeing some of the issues you had be resolved is also satisfying as a customer. I’ve built small products, worked for startups etc. I get the feeling that most devs are terrified to actually talk to the customers they build for. I’m not, because of my background, but most devs don’t have that background.

citizenkeen 4y ago
So you’re the reason Azure’s interface is constantly in flux.
jrib 4y ago
I've had Atlassian's bitbucket team reach out to me after I expressed frustration in a survey. It was a manager and a developer on the call. They listened intently. I think the call lasted at least 30 minutes. I think bitbucket improved a lot over the last few years. I like to think that practice of talking with users was a significant part of that.
tchock23 4y ago
Andrew Mason reached out to me to do an interview about his new startup Descript. Dude is worth a lot of money from his Groupon days and here he is doing one on one calls with his customers. I think it’s a big reason why Descript is a great product. Even if he isn’t the one doing that forever, it sets a huge cultural expectation that listening to customers matters.
cpursley 4y ago
Did they (Azure) schedule the call or randomly dial you up? I'm trying to figure out how to do this with our customers without disrupting them (their workflow, day). And for busy customers, it seems like maybe these types of calls are not high priority enough (vs "app is down" situations) to get them to schedule. I will say, customer development (prospects) are helpful. I've learned so much about what to and not to spend time building. I'd like to get the same milage out if existing customers.

mkl95 4y ago

I used to do this when I was leading the development of an internal tool used by a small research department. Researchers were initially using a clunky prototype that had not received any end user feedback. By meeting them regularly I was able to fix their pet peeves, add the features they needed, and remove useless stuff. Doing this for an internal tool is of course relatively easy, but ever since I have been wondering if it would work for B2B software.

Lutger 4y ago
Yes it works, and it works really well in my experience, but only if the context is right. The trick is you need to get the real end users on board at least, in addition to and alignment with the one who is calling the shots and/or owning the budget. Most of the time in business, the person making the decisions is not the one who has to live with the consequences. So for B2B the ability of the decision makers to do sensible things is your limiting factor. You need to really partner up with the decision maker(s), and get a feel for whose problems you are actually solving. Sometimes there's this political layer over the actual problems that is making things more complex, and which is not actually explicit. Not understanding this layer can lead to a lot of frustration in my experience.

shsbdncudx 4y ago

Listen to your customer. Agile is fine, but the product it’s become is an abomination. It’s about reducing the cost of learning. That’s it.

whoevercares 4y ago

This is a quite ok framework for greenfield project in Big Tech IMO, where we have this exact problem - debating the strategy from Q1-Q3 and starting coding in Sept and deliver craps

BasilPH 4y ago

"The Mom Test"[^0] is an excellent and short book about how to conduct those talks that I can highly recommend. It teaches you how to truly listen, and not bias the person you're interviewing. Two points that stuck with me: - Humans are bad at estimating, so make your questions very concrete. Don't ask "How often do you look up recipes on your iPad", but rather "How often did you use your iPad for recipes last week?". - Nobody likes telling somebody else that their baby is ugly. Show the prototypes at the end of the interview, once you learned everything about the problem they had to tell you. If you show them your solution too early, you'll bias them. [^0]: https://www.momtestbook.com https://www.momtestbook.com