Talking to your customers: a disruptive Agile framework
lucasfcosta.com
lucasfcosta.com
- 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.
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.
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.
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.
What has your experience with that been like? Or do you know how to avoid it?
You can't be tricked into giving out your cell phone. If you don't want to give it out - don't.
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.
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.
- 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
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.
You can easily uncover in an job interview if they honor those preferences.
* How is the customer involved in shaping the software? Give specific examples.
* Who decides what will be developed? Where does my role fit in?
* Will I be able to ship production code my first week? (Why not?)
Et cetera.
Even better: come up with your own manifesto of preferences for ways of working.
And then score potential employers and your teams against them.
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
and
"Individuals and interactions over processes and tools"
to argue that writing code comments, tests and documentation wasnt worth investing in when we can all just talk.
This was after a series of disasters that code comments, tests and documentation would all have helped with. It's perhaps hard to imagine that this would be controversial but it was - the fact it was 10 years ago and we were under pressure to deliver can perhaps partly explain why.
Try as I might I couldnt argue that his interpretation was wrong. I stared at the words and was shocked when I realized that it was actually perfectly valid.
I have my own understanding of "good agile" and no doubt a lot of developers share it after many decades of good experiences and bad experiences and it arguably means putting processes and tools over individuals and interactions some of the time - like using a linter/autoformatter over arguing about formatting.
I dont know what we need but probably it looks a lot more like an updated version of the joel score than the vague soft focus angel tinged* crap that is the agile manifesto.
For what it's worth, I think your list is also a bit vague.
* I swear that the of the agile manifesto web design was also stolen from a baptist church.
So your colleagues view was a pretty extreme one compared to the moderation shown there. But like any philosophy you end up with fundamentalists taking things too far even in the face of reality being more complex. It’s terrifyingly dogmatic to argue from scripture rather than pragmatics.
I agree that arguing from scripture is awful. I havent tried to do it since. I would like to see some other sort of anti-waterfall set of principles that I could get behind though.
The problem is the brand has been captured by consultants selling something that doesn't jive with the original ethos.
You were supposed to talk to the customers. Now you have dedicated POs that determine what the team will work on, but they're also too junior to talk to the customers. It's okay though, you have dedicated PMs that'll talk to the customers, right? Only they're typically to busy pushing a personal agenda to climb the corporate ladder to actually care.
It's cool though, we're agile so we can just change the process? Nah, there's now there's extremely prescriptive processes. Heaven forbid you don't find the hour long retrospectives, that you can't action anything from, useful.
So basically it boils down to the daily status report which ensures you a) show up on time and b) report on your commitments, and generally being forced to overcommit by committe on really short deadlines, so you can be pressured to work free overtime because apparently its your commitment?
Of course, not everyone abuses agile like this. But they don't typically advertise, sell, or even really talk about agile all that much.
In general - I consider "agile/scrum master training" on a resume as a pretty serious black mark, for basically the same reason: The training is all from consultants who preach bs to sell courses and products to management - very rarely does the training encourage simple acts like "talk to your customers" or "let your devs shadow a user" or even "treat your team like people". It's all process over people - the opposite of the intent.
No real engineering team exists in a vacuum, so more often than not, all Agile processes degrade into waterfall.
If you're lucky and you live in a pure software world with no 3rd parties imposing deadline dates on you, great. In my experience, those worlds are few and far between.
There will always be major events that are locked to fixed dates, like conferences, launches and many things that are impacted by launches (like hiring new teams to be using the new systems that we were supposed to be building). This does not mean this company sucks, or working at this company sucks, it usually means this company is profitable.
"Waterfall" is starting to get twisted into some sort of virtue signaling for folks that like to complain about deadlines.
Managing this tension is what we all need to be good at - there's definitely no silver bullet or perfect methodology to manage this, because it is always evolving.
So-called capital-A “Agile” - including the thing that people call Scrum, SaFE, all the other hard coded nonsense - are just turnkey processes, churned out by authors who got lucky, that tend to be implemented as silver bullets, with almost no regard for the actual principles and value of the manifesto from which they draw their name.
https://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-s...
> Keep the values, keep the principles, think for yourself. A core premise of agile is that the people doing the work are the people who can best figure out how to do it.
Brilliant.
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.
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.
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.
You talk to customers to better understand the problems they face and how valuable a solution might be.
Not for ideas or suggestions.
Once you've built a thing, you talk to customers to understand _how well_ your thing solves their problem.
None of this necessitates incremental solutions.
Listening to a customer is not some manual variant of a mechanical A/B test. You really need to immerse yourself in their world and peel off all the things they say that gets in the way of the problem. Its a skill of empathy.
I think the real 10x leaps that 'create new markets' don't just conjure up problems out of thin air: they are novel ways of solving a familiar problem. At best, they solve problems for which people have come to accept the lack of a good solution and thus don't articulate as problems anymore.
In the most extreme case, an innovation creates a new problem in the sense that suddenly a desirable alternative for the status quo can be imagined where it couldn't before. To me, that still implies the innovator just deeply listened to the customer and discovered a potential problem others failed to recognize.
Cause that's what growth hacking gurus tell me on YouTube .
/s (hopefully that was obvious to all)
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.
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.
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.
;)
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.
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.
Agile is fine, but the product it’s become is an abomination.
It’s about reducing the cost of learning. That’s it.