I can feel the disagreements stirring amongst the HN crowd[0]. You know, this is an observation I've made sub-consciously a thousand times and I really appreci

I can feel the disagreements stirring amongst the HN crowd[0]. You know, this is an observation I've made sub-consciously a thousand times and I really appreciate you putting that into words. In my experience, frequent check-backs with the customer -- and planning those "detours of development to make something visible" or "prioritizing this with a fake back-end to make something visible" (which we may do anyway if we have front-end/back-end working simultaneously) -- I find the most useful parts of working this way have nothing to do with the usual Agile Suspects[1]. My observations come from the lens of being employed by a few companies where I was a Senior developer with one or two Mid/Junior levels designing all or a major part of a product for a third-party (usually IoT or fully digital product someone paid us to design/develop). This may not apply to "I make a SaaS product I sell to customers" because of the closeness of working with them, but some of them likely do: (1) Willingness of the customer to engage in regular communication is (anecdotally -- my observed) biggest factor to success. Ya know what, sometimes it doesn't even matter, either. I did three jobs for an oil company everybody's heard of, paid for via consulting dollars given to them by Microsoft. They met with us about five times for three products with the vision being to roll out one of them to "every employee except for the clerks" and the rest back-end to the complete appropriate environment. All three were met with praise and brought us future work. Not one of the three was deployed beyond test capacity (of the something-ungodly-like "150,000 user licenses" they paid for, we logged all of ten, it was sad). (2) If they are unwilling, or you suspect they are dis-engaged, meet with "your contact over at the company" and have an off-the-record (but you know it's not) careful conversation to discover the reason for the dis-engagement. We were straight-up told "Oh, no, they do this all the time. They have to spend the consulting dollars." Emphasis provided verbally but never explained. It was said as though it could have been finished off with "or they will be fired" -- despite that being absurd; that was the level of intensity. Sometimes, though, you find out that you're not listening (or in a larger forum, they're not willing to tell you what the elephant in the room is) and it might be the only opportunity you have to fix it. A past product I botched pretty well had this issue. I had a customer become disengaged on a product I was working -- up to the point of actually shopping the product to another company half-way through. There's a lot lost in the detail, but it came down to them paying us to develop a product with the assumption that they'd have total control over the layout of the data in the database (despite not mentioning it, nor it being specified in any useful way in our contract). Unfortunately, the product had about one way it could be laid out in the database -- and it wasn't a way this unsophisticated customer would be able to just run a few simple SELECT queries on. Or, that's what I thought the problem was. Once I rang up their "one terribly abused IT guy", and exchanged a few war stories from my work history, I said "What's up with Tom trying to force this ridiculous schema down our throat?" He laughed and said "The money they budgeted for the project covers everything except the admin tool and Tom knows he'll never grasp your Schema well enough to write it himself[2]." They'd been telling us they'd pay a second invoice for the Administration tool and this was confirmation that was out, which I'd already scoffed at but this was absolute confirmation. I wish I could say we did the right thing with the information and it all worked out but, unfortunately (and this was out of my control), nothing was done with it. (3) Frequent communication leads to higher engagement which leads to the feeling of partial ownership. I saw this at two shops -- one where we had almost no competitors developing against the APIs we were experts at -- we were expensive, so customers became invested in the success of the final product. They were engaged because "if it failed, they might not have jobs." But the other shop was unique. We provided a service that, on the surface, looks a lot like a whole lot of other things, including things sold by Microsoft. But the product was designed targeting three, specific, narrow verticals. These verticals, for at least two huge brands, had nothing that really met their needs so our pitch was "we'll make a version of our product designed for your company with you." And we did. We responded to every little detail asked down to ensuring the buttons/other things looked like every other internal web app they used, branded in a manner that completely hid that it was a SaaS product we sold with another name or that there was another company involved. But we knew every single big brand had a department that does this even if they hire a whole other company to manage the majority of it. So we ensured the contracts allowed for us to re-brand and re-sell it to every one of their competitors (and because of the product, it ends up benefiting them if the other company is as successful as they are). Fast forward a few years, and those two companies have been purchased three times over, almost ended up becoming one, and each time the question of "Should we get rid of Super-App?" wasn't just "No", but met with stories from the department head of "How it was a short meeting after they heard from me and (the three other folks we built it with)." They continue to pay the yearly renewals and work with us to develop out more things every few months. We've re-done this with the other verticals to the point of "we've captured all of the low hanging fruit in that vertical" to "we are a very competitive product in that vertical" but where we're deployed, our customers love the product. Those early customers feel actual loss when people talk about replacing it because they feel like they had a part in its creation. (4) Frequent communication means you actually understand what your customers are saying. The biggest problem with talking to customers is they ask for things that have nothing to do with what they want to accomplish. "Can I save that to a PDF file?" "Why?" "I want to print it in a consistent format?" "I can put a print button on the page that will do that?" Customers get hung up on specifics of what they want driven by limits of what they believe things can do. If I had a dollar for every time a customer was surprised it was easy to do something "that, I'm fairly certain I could make work in IE 6 with a little effort." That's not a "har har, the customer iz stupiDZ", it's "that's not their job", "that's mine." But they're trying to translate a little of what they're asking into "Software Development Shop" because to explain it to you in their language, you better know a whole lot about manufacturing headlight bulbs (or whatever), and you're trying to translate everything into headlight bulbs. Over time you understand each other's languages and know when to say "... wait a minute, are you trying to ...?" with results that work out a little better than Clippy. [0] Let's pick the topics: "Anything in the category of project management, scrum, agile", and the "Customer's Don't Know What They Want" (aka Listening to the Customer Results in Features They Don't Use(tm)), the "Startup Advice Doesn't Apply Outside of Startups" ... but that has nothing to do with what I wanted to say. [1] Building the product this way ensures that the customer and you are on the same page with what the end result should actually be. Nothing explains how it's going to work than a UI that kind of does some of the things the working thing will do. [2] I did inquire why "internal IT Dynamo", who I knew was a programmer from outside circles, wasn't being forced to write it. He said "I told them I'd quit." It sucked because I was so proud of this design -- it performed brilliantly despite being 6th normal form for 3 tables and it actually had to be 6th normal form to do what I was trying to do. Even better, because it's such a bitch working with that data, I put instead of update/insert/delete triggers on a set of views so "if you wanted to screw with it in SQL Management Studio", go ahead, all enforced by simple constraints, 1/4 the code that was ultimately required by the customer's insisted-upon design but -- importantly -- didn't grow table data exponentially for every configuration added resulting in the whole system falling down after setting up about ten configurable products.