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.
One of the concerns I have about calling customers come from my previous experience with it: once they get contact details to a technical person, they will contact that person for every single problem they have. Do this with enough customers, and you will barely get any real work done. Not to mention that I'm not great at juggling lots of threads of conversation – that's part of the reason why I'm not in customer-facing roles, so I'm bound to drop some.
What has your experience with that been like? Or do you know how to avoid it?
If you're calling from a business line, the outgoing number should be the main line, not your direct line. If you're doing this on a cell phone, just block the number. Yes, your answer rate will go down, and you'll have to leave voicemails, but eventually when they see a blocked number they'll think "oh it's probably kqr" which won't be any worse than an unknown number anyway. If they ask for your contact details, give them an email or whatever your preferred method is.
You can't be tricked into giving out your cell phone. If you don't want to give it out - don't.
Maybe train technical staff in how to set boundaries and deal with customer calls in a manner that doesn't lose customers and doesn't eat all their time?
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.
I just picked up the phone and they were there (they always introduced themselves and asked if it was a good time to discuss X -- I assume they'd just reschedule a time if it wasn't a good time). There was no notice that they were going to call. I was usually bored and driving, which is about the only time I pick up a call from an unknown number. Azure is b2b, so I think there's a reasonable expectation that <em>someone</em> will pick up the phone.
Um. It was more like “Hello, is this (name)? Hi, this is (name), the product manager from (team) at Azure. I’ve also got (name) on the line, one of our devs. We were wondering if you have a few minutes to tell us about your experience with (thing team works on), and answer a few questions.”
I'm sure they get a lot of hang ups, but there is a clear difference between someone who can barely speak English calling you from a call center "to discuss the account" or whatever, and a native speaker calling from (presumably) their home or a quiet office, using your name, and who already knows what products within Azure you're using. It's pretty obvious from the get go it's not a scam.
Even if it wasn't someone from Azure, it's unclear what scam "Do you have a few minutes to answer some questions about how you use our product so we can better understand your use cases" could possibly be.
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.
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.
- 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)
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.
I first realized the problem when somebody hit me with:
"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.
The following on bit from those statements is:
“That is, while there is value in the items on
the right, we value the items on the left more.”
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 dont think it was dogmatism. I think they genuinely didnt think we had time to write tests, etc. and when I argued that we should do it to be more "agile" because we'd all committed to being agile up front (in theory) they googled what the principles and said "look, thats not what agile says".
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.
You can follow agile methodologies while working on a fixed schedule, but if the timeframe isn’t flexible, then the scope needs to be. Fill up the backlog, prioritize it by importance, and what’s done by the deadline is what’ll be delivered. If you get work done reliably and at a consistent pace while tracking velocity or throughput, you can use that data to get an idea of what you’ll manage to deliver.
The reality is that as soon as one of your customers has a date as a deadline, everything crystalises behind that into a series of deadlines and hence into waterfall.
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.
Amen, but forget about external influence - if you work in a business that is profitable, you're certain to bump into coworkers outside of technologies that live in a pure deadline-driven world. That's business, and it is not negotiable.
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.
> 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.
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.
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.
> Remember: it’s your job to come up with the solution, not the customer’s. When you go back to ask them questions, ensure you’re not simply asking them to design the solution for you. If they could do that, they’d probably have done it already. If they could have done it but didn’t, it’s because the problem doesn’t matter much.
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.
Exactly. This is the most important part people just don't get. Customers are really, really bad at solving their own problems. In my domain, they all come up with a crude and barely functioning variant of excel in a web browser.
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.
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.
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.
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).
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.
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.
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.
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.
"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.
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).
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.
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
- 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.