7 ms·

It is really funny, I agree with this 100% but also think because of the new norm of instant gratification this person is totally wrong. I have customers that a

by ewams 10y ago

It is really funny, I agree with this 100% but also think because of the new norm of instant gratification this person is totally wrong. I have customers that all the time state they want to move to an openstack platform but have no programmers or unwilling to hire programmers. So of course we go down that path, look at the capex and opex and their brains explode. Then we look at aws/azure/vCloud and regular internal cloud with its associated costs and they come back from their heart attacks. If you are a services company, he is right, you should be focusing on outcomes. But, if you can't tell me in 2-3 sentences what problem you are solving and how it benefits the customer you are doing it wrong. This is a world of businesses and businesses need to make money, usually. Everyone gets so caught up on the new hot thing or the new "revolution" or what the competition is doing without thinking of what problem they are trying to solve or what actual value they are providing. This article says they provide outcomes, sure I can provide outcomes by moving you to SAP, or VDI, or hyperconverged, but what problem is this solving? Don't tell me it "cut costs", it rarely does and lots of people smarter than me have shown that cutting costs are not the top priority of most leadership. Back to the point of the article. I have made a lot of money in consulting. I now sell consulting services. You know how I do it? "Yes Mr customer how are you? Cool great, I am fine thanks. So what problems does your organization have, what are your goals, and how can I help you?" Boom. You are all welcome. Don't talk about product or you will lose to me or someone better. Don't talk money or you lose. Don't talk fads or you lose. Talk about the business and how you will help it reach its goals, overcomes it's problems, and grow!

StillBored 10y ago
This! I previously worked for a small software company that frequently got itself lost in the upgrade treadmill (its going to take N man months to upgrade underlying technology X/Y/Z to the latest versions). Yet in the end, I kept asking, what does technology X/Y/Z provide to the product that benefits the customer. Those questions frequently didn't have satisfying answers. So, your not the cool, forward looking engineer when you favor using a 5 year old toolchain to build your product. OTOH, your also the engineer that doesn't have to come in on weekends to debug the death march bug that ends up being a result of doing the upgrade.
- draw_down 10y ago
  Sure. But, have fun trying to get a new job when you're using 5 year old tech. In other words it's not just about pride or being one of the cool kids.
  - genericone 10y ago
    So use 6 month old tech because you need to keep up with the cool kids who are hiring for that new tech specifically? Hamstring your current company in order to stay on top of tech/framework trends?
  - golergka 10y ago
    Say that to Cobol devs.
    - chris_wot 10y ago
      If you do, say it loudly or they might not hear you.
  - ehnto 10y ago
    I can see your viewpoint, but I have to say that trying to keep up with the tooling treadmill has many tradeoffs. If there is a new framework or tool to know about every few months and you change job every three, you will be spending all your time re-learning some strange new wheel and taking energy away from truly excelling at your current tool set. On top of that, if we chase the carrot of technology we will always be using tools that are less than a few years old. In otherwords, un-tested by time and immature code bases without useful ecosystems and best practices. RiotJS for example, there is a way it's designed to be used, and it is idealogicaly sound. But also naive. That way will evolve a lot over time as even just a small project revealed a dozen or so pain points to solve, that haven't yet been addressed by the community. But working on an older codebase, communities have usually solved a lot of those problems with process or ammendments, and there is a wealth of information available.
  - madeofpalk 10y ago
    There's a middle ground - don't upgrade systems for the sake of upgrading, but maybe if you're building something new or working on a sideproject, investigate newer technologies.
bobwaycott 10y ago
Same here with regards to consulting. Clients pay and pay well to be able to pick up the phone and say, "We are having trouble realizing our goals/expectations/efficiencies in area X. How can you solve that for us and make our lives easier?" And, just like that, another contract is drawn up and another invoice is sent. They don't care about the underlying tech. They only care about results, and what the results cost them. One-time consulting fees nearly always win over the prospect of hiring staff to take on the task, especially given that my incentive as a consultant is to time-gate a project and get it out the door so I can take on another.
jclan 10y ago
This kind of thinking doesn't factor in how many Robots work in enterprise software. They come programmed. You want to alter programming, esp in enterprise software, you need to be very high up the food chain. Any other route you take will be met with glazed looks and 'ok great...um...shall we go get a sandwich now'.
vidarh 10y ago
I fully agree with this. Not only should you not focus on product, but when clients bring up product you should of course listen carefully and respectfully, but you need to consider that they are even then expressing ideas about how to solve their problems. Those ideas may be well thought through, but very often they are not, and comes down to trying to explain what they need based on what they know. If a client says "we need product X", sometimes they really need it, but often what they are trying to communicate is "we need the stuff product X's marketing material says it will solve", and even that may be imprecise Someone coming in quoting on what they say rather than what they answer when you ask probing questions about their actual problems will often quote for the wrong thing. And more importantly: Quote for something that someone else will be explaining to them why is the wrong thing while quoting for something more appropriate. Doesn't help if you come in with the best price if someone else has made your solution irrelevant. The other aspect is that people often value the solution to a problem far higher than they value a product. I have built a tool that I'm starting to roll out a service around now. And the interesting thing is that when I've talked to people about it, it quickly became clear that if I showed them screenshots of my admin interface and explained the software, they started comparing it to $20/month services that in fact deliver far less value in terms of results, but they still found it hard to see it as something more expensive. When I instead approach it entirely in the abstract, and show people analytics of the outcomes and never tell them I have a pretty web-based interface, and never suggest they'll get a login to anything, people consistently value the service 10x to 20x higher. Now, this doesn't work for everything - the reason people value it so high in the latter case is that the analytics makes it clear it deliver results that would cost them in that region otherwise. But the moment I start to describe it as a product, people go blind to the outcomes and value it based on other criteria. tptacek and patio11 have touched on this previously too when talking about how to get your rates up by focusing on value delivered, and avoiding billing in small increments (e.g. bill daily rather than hourly, or even bill by the week or by the project if you can). But beyond applying just to the price, the overall principle also greatly affect whether or not you'll get a deal at any price. Someone may even suggest the exact same technical solution as you, cheaper, but still lose out if they focus on the product and you're selling problem solutions and visions of where it will get them next. E.g. I had a client meeting yesterday to walk through a proposal I'd sent, and the entire meeting involved me telling them what problem each part would solve and what that'd enable next. They sat there grinning through most of it, and kept starting to discuss additional work they just thought of that this would enable them to do later, and cost came up just very briefly at the end. Never mind the initial contract - selling them on the idea and the problem solutions now rather than technical details of a specific product likely already did 90% of the job of selling in 3x+ more work down the line.
devonkim 10y ago
I've come from your perspective before to customers (talk about the pain points, focus upon problem-resolution fit not tech, etc.) and it's awful hard to tell customers that have 80% of costs being related to labor and have reasonably well-performing technology that when they're talking to you only because you're trying to cut costs directly in your SOW it can be frustrating when touching that 80% is completely off limits and a political landmine. Almost all the big vendors and sales teams start with the approach of looking for problems and trying to re-message their products and services to appeal to the problems of their C-level customers, not the engineers (whom never make the vendor relationship decisions). Several years ago everyone was "cloud-washing" their products to tell CIOs "oh yes Mr. CTO, we're ready for your cloud initiative" by slapping on a web frontend to their managed services and boxed software when they didn't have anything before to maintain a relationship. Those are red herring projects though I've found - it's just another way to keep vendors on their toes. Another problem is that accurate problem statements can be very hard to get to without escalating to higher level managers that it turns out are oftentimes swayed by existing vendor relationships to get something done more effectively. From here, I simply have to ask "are you happy with the results your vendors have promised compared to what you expected?" and everyone complains about cost but you need to get away from that conversation honestly if possible - because IT at a company will never, ever, ever cost too little since it's a cost center.
hinkley 10y ago
The older I get the more I feel like we're an accelerate version of the fashion industry. At least in fashion you can make an excuse that the design is thirty years old and most people don't remember the last time we did this. With software it's every six or seven. It's hard not to judge my peers for having such short memories. We were in the midst of one of these upheavals when I first started, and so I learned programming in that environment. It also means I have one more cycle than most people near my age. Now it all looks the same to me, and I understand those people who wanted to be more conservative. In fact I probably owe some people an apology.
- digi_owl 10y ago
  "High fashion" as as much an art installation as it is clothing. Thus what i see with a lot of IT these days, is an invasion of "artists". Personally i blame it on the web being co-opted by print media. This in turn brought in "media studies", that in turn brought in the "artists". Notice how again and again there is an attempt at turning the web into a printed booklet. Early on it was done using flash. These days its JS and mangling the behavior of scrolling.
api 10y ago
> Everyone gets so caught up on the new hot thing or the new "revolution" or what the competition is doing without thinking of what problem they are trying to solve or what actual value they are providing. These are my exact thoughts about how we now have like two dozen explicitly Docker-releated startups. Because Docker. Docker docker docker docker docker.
codingdave 10y ago
"Don't talk about product or you will lose to me or someone better." I was with you until that little gem. Products fill a known need, solving a problem shared by many organizations. They don't claim that they can help everyone with all problems... but they do solve a specific problem, and if you have that problem, products are good things. You can flip the attitude the other way by saying that consultants who act like everything they do is better than everyone everyone else will lose when working in well-established problem areas because they re-invent wheels. Expensively. The truth is that good business can be done from either a broad consulting perspective, looking for new ways to help a specific customer... or from a narrow product perspective, solving a specific need for many customers. One is not inherently better or worse than the other. Just different.
- enraged_camel 10y ago
  >>Products fill a known need, solving a problem shared by many organizations. They don't claim that they can help everyone with all problems... but they do solve a specific problem, and if you have that problem, products are good things. The point is that customers care about solving problems. They don't care about whether they are buying Product A or Product B to solve that problem. That's why you need to keep the conversation focused on the customer, their problems and potential solutions, and not the product.

by ewams 10y ago

StillBored 10y ago

This! I previously worked for a small software company that frequently got itself lost in the upgrade treadmill (its going to take N man months to upgrade underlying technology X/Y/Z to the latest versions). Yet in the end, I kept asking, what does technology X/Y/Z provide to the product that benefits the customer. Those questions frequently didn't have satisfying answers. So, your not the cool, forward looking engineer when you favor using a 5 year old toolchain to build your product. OTOH, your also the engineer that doesn't have to come in on weekends to debug the death march bug that ends up being a result of doing the upgrade.

draw_down 10y ago
Sure. But, have fun trying to get a new job when you're using 5 year old tech. In other words it's not just about pride or being one of the cool kids.
- genericone 10y ago
  So use 6 month old tech because you need to keep up with the cool kids who are hiring for that new tech specifically? Hamstring your current company in order to stay on top of tech/framework trends?
- golergka 10y ago
  Say that to Cobol devs.
  - chris_wot 10y ago
    If you do, say it loudly or they might not hear you.
- ehnto 10y ago
  I can see your viewpoint, but I have to say that trying to keep up with the tooling treadmill has many tradeoffs. If there is a new framework or tool to know about every few months and you change job every three, you will be spending all your time re-learning some strange new wheel and taking energy away from truly excelling at your current tool set. On top of that, if we chase the carrot of technology we will always be using tools that are less than a few years old. In otherwords, un-tested by time and immature code bases without useful ecosystems and best practices. RiotJS for example, there is a way it's designed to be used, and it is idealogicaly sound. But also naive. That way will evolve a lot over time as even just a small project revealed a dozen or so pain points to solve, that haven't yet been addressed by the community. But working on an older codebase, communities have usually solved a lot of those problems with process or ammendments, and there is a wealth of information available.
- madeofpalk 10y ago
  There's a middle ground - don't upgrade systems for the sake of upgrading, but maybe if you're building something new or working on a sideproject, investigate newer technologies.

bobwaycott 10y ago

Same here with regards to consulting. Clients pay and pay well to be able to pick up the phone and say, "We are having trouble realizing our goals/expectations/efficiencies in area X. How can you solve that for us and make our lives easier?" And, just like that, another contract is drawn up and another invoice is sent. They don't care about the underlying tech. They only care about results, and what the results cost them. One-time consulting fees nearly always win over the prospect of hiring staff to take on the task, especially given that my incentive as a consultant is to time-gate a project and get it out the door so I can take on another.

jclan 10y ago

This kind of thinking doesn't factor in how many Robots work in enterprise software. They come programmed. You want to alter programming, esp in enterprise software, you need to be very high up the food chain. Any other route you take will be met with glazed looks and 'ok great...um...shall we go get a sandwich now'.

vidarh 10y ago

I fully agree with this. Not only should you not focus on product, but when clients bring up product you should of course listen carefully and respectfully, but you need to consider that they are even then expressing ideas about how to solve their problems. Those ideas may be well thought through, but very often they are not, and comes down to trying to explain what they need based on what they know. If a client says "we need product X", sometimes they really need it, but often what they are trying to communicate is "we need the stuff product X's marketing material says it will solve", and even that may be imprecise Someone coming in quoting on what they say rather than what they answer when you ask probing questions about their actual problems will often quote for the wrong thing. And more importantly: Quote for something that someone else will be explaining to them why is the wrong thing while quoting for something more appropriate. Doesn't help if you come in with the best price if someone else has made your solution irrelevant. The other aspect is that people often value the solution to a problem far higher than they value a product. I have built a tool that I'm starting to roll out a service around now. And the interesting thing is that when I've talked to people about it, it quickly became clear that if I showed them screenshots of my admin interface and explained the software, they started comparing it to $20/month services that in fact deliver far less value in terms of results, but they still found it hard to see it as something more expensive. When I instead approach it entirely in the abstract, and show people analytics of the outcomes and never tell them I have a pretty web-based interface, and never suggest they'll get a login to anything, people consistently value the service 10x to 20x higher. Now, this doesn't work for everything - the reason people value it so high in the latter case is that the analytics makes it clear it deliver results that would cost them in that region otherwise. But the moment I start to describe it as a product, people go blind to the outcomes and value it based on other criteria. tptacek and patio11 have touched on this previously too when talking about how to get your rates up by focusing on value delivered, and avoiding billing in small increments (e.g. bill daily rather than hourly, or even bill by the week or by the project if you can). But beyond applying just to the price, the overall principle also greatly affect whether or not you'll get a deal at any price. Someone may even suggest the exact same technical solution as you, cheaper, but still lose out if they focus on the product and you're selling problem solutions and visions of where it will get them next. E.g. I had a client meeting yesterday to walk through a proposal I'd sent, and the entire meeting involved me telling them what problem each part would solve and what that'd enable next. They sat there grinning through most of it, and kept starting to discuss additional work they just thought of that this would enable them to do later, and cost came up just very briefly at the end. Never mind the initial contract - selling them on the idea and the problem solutions now rather than technical details of a specific product likely already did 90% of the job of selling in 3x+ more work down the line.

devonkim 10y ago

I've come from your perspective before to customers (talk about the pain points, focus upon problem-resolution fit not tech, etc.) and it's awful hard to tell customers that have 80% of costs being related to labor and have reasonably well-performing technology that when they're talking to you only because you're trying to cut costs directly in your SOW it can be frustrating when touching that 80% is completely off limits and a political landmine. Almost all the big vendors and sales teams start with the approach of looking for problems and trying to re-message their products and services to appeal to the problems of their C-level customers, not the engineers (whom never make the vendor relationship decisions). Several years ago everyone was "cloud-washing" their products to tell CIOs "oh yes Mr. CTO, we're ready for your cloud initiative" by slapping on a web frontend to their managed services and boxed software when they didn't have anything before to maintain a relationship. Those are red herring projects though I've found - it's just another way to keep vendors on their toes. Another problem is that accurate problem statements can be very hard to get to without escalating to higher level managers that it turns out are oftentimes swayed by existing vendor relationships to get something done more effectively. From here, I simply have to ask "are you happy with the results your vendors have promised compared to what you expected?" and everyone complains about cost but you need to get away from that conversation honestly if possible - because IT at a company will never, ever, ever cost too little since it's a cost center.

hinkley 10y ago

The older I get the more I feel like we're an accelerate version of the fashion industry. At least in fashion you can make an excuse that the design is thirty years old and most people don't remember the last time we did this. With software it's every six or seven. It's hard not to judge my peers for having such short memories. We were in the midst of one of these upheavals when I first started, and so I learned programming in that environment. It also means I have one more cycle than most people near my age. Now it all looks the same to me, and I understand those people who wanted to be more conservative. In fact I probably owe some people an apology.

digi_owl 10y ago
"High fashion" as as much an art installation as it is clothing. Thus what i see with a lot of IT these days, is an invasion of "artists". Personally i blame it on the web being co-opted by print media. This in turn brought in "media studies", that in turn brought in the "artists". Notice how again and again there is an attempt at turning the web into a printed booklet. Early on it was done using flash. These days its JS and mangling the behavior of scrolling.

api 10y ago

> Everyone gets so caught up on the new hot thing or the new "revolution" or what the competition is doing without thinking of what problem they are trying to solve or what actual value they are providing. These are my exact thoughts about how we now have like two dozen explicitly Docker-releated startups. Because Docker. Docker docker docker docker docker.

codingdave 10y ago

"Don't talk about product or you will lose to me or someone better." I was with you until that little gem. Products fill a known need, solving a problem shared by many organizations. They don't claim that they can help everyone with all problems... but they do solve a specific problem, and if you have that problem, products are good things. You can flip the attitude the other way by saying that consultants who act like everything they do is better than everyone everyone else will lose when working in well-established problem areas because they re-invent wheels. Expensively. The truth is that good business can be done from either a broad consulting perspective, looking for new ways to help a specific customer... or from a narrow product perspective, solving a specific need for many customers. One is not inherently better or worse than the other. Just different.

enraged_camel 10y ago
>>Products fill a known need, solving a problem shared by many organizations. They don't claim that they can help everyone with all problems... but they do solve a specific problem, and if you have that problem, products are good things. The point is that customers care about solving problems. They don't care about whether they are buying Product A or Product B to solve that problem. That's why you need to keep the conversation focused on the customer, their problems and potential solutions, and not the product.