First, everyone needs a place at the table. There is an ungodly amount of distortion, omission, and loss in transmission between prospect/customer and engineering. If you have a prospect, meetings should include people from business, and engineering. If in any case only one person was there, this person should write up their notes or be downloaded/debriefed while the memory is still fresh. If someone is updating you on the phone get the most you can when they just got out of the meeting. Sometimes you ask a question and they can go back to the person they just met who's probably having a break by now and ask, take copious notes and dispatch them. If you got anything wrong, they'll correct.<p>Written meeting notes should be disseminated, and then corrected and augmented so that:<p>- Those who weren't there get an idea of what was actually said (we have meeting minutes in version control and anyone in the company can pull them and know exactly what I discussed in X town at which hour with whom)<p>- Those who were there realize they didn't hear/understand the same thing or plug holes. One catches what another has missed.<p>- Track rationale and decisions: All development through issue tracker. Avoid the "why was that feature added/removed two months ago again and now it's to be removed/included?" and not knowing why.<p>This should bring everyone to the same "initial conditions". If you don't do that, it's telephone game and you get a human-centipede like result.<p>Include form to request a feature in the product itself. Directly from the users so there's no distortion. Everyone should get that issue.<p>Also, if there's no product there is no business, which makes me wonder why the tech side is taking the backseat in a fintech startup. Fintech is like an airplane: you take a bus, you add wings, and you have an airbus that can travel faster and farther. Remove the tech, and it's just finance.<p>Add monitoring and analytics. We're working on that ourselves after putting out a lot of fires that looked the same.<p>Second: customers drive product roadmap in terms of <i>raw data</i>. Whenever users or customers ask something or raise an issue, ask yourself what is the underlying issue and what are they <i>really</i> trying to do. "Job to be done". Drill vs hole. Customers complaining is similar to patients complaining: they'll tell you about <i>symptoms</i> and then want you to fix those symptoms and they'll propose solutions and features. You gently take notes, and then dig deeper.<p>The analogy I use is that customers will ask for a robot with IoT and blockchain support that automatically integrates with Amazon API and orders mops, tracks the item, and has AI and image segmentation and recognizes Amazon drone, and receives the mops and automatically loads them. Because AI, blockchain, and IoT. Yes, it's not a sentence.<p>Your job is to ask why, figure out they always find water on the floor, and then look up and find there's a leaky pipe, then fix the leak.<p>In other words: do not really listen to the "implementation" or the "solution" customers propose. These only fix symptoms and are easily swayed by whatever piece with a clik-bait title prefixed by "This AI robot" someone with 2 minute attention span has written that the customer half read taking their morning coffee, and wanted to bring to the product not to be left behind by the competition.<p>What one really looks for is the problem. The problem almost never manifests itself, you have to dig to get it. It's muddy. People could be pissed at you because "What do you not get in an AI IoT robot that orders mops?". This is where having social skills and getting good at interviewing comes in handy.<p>People demands and their behaviors are the solutions <i>they</i> have come up with to a <i>problem</i>. The problem is that they almost never tell you about the <i>problem</i>, and you may have a better solution. Think of it like code review: code I push is my implementation or a solution to a problem. The implementation is dictated by my skill, experience, sophistication, sleep I had yesterday, etc. Code review helps find better ways.<p>Third: all developers do support. This focalizes and aligns everyone. You have a hundred issues in your issue tracker. You have thought of great features. A lot of the issues are about bugs.<p>We opened our internal ML platform to about 30 students of our colleague so they could get a one click notebook with all libraries installed, a lot of RAM, a sweet K80, and hundreds of gigabytes of data for their project. We added the students to a dedicated Slack workspace. The platform is not ready, but precisely. This is a jolt.<p>Users would complain about something. We would notice a pattern. We would investigate, then figure out what to do.<p>They're doing two things:<p>- Exposing things we wouldn't have found<p>- Putting the finger on what hurts the most amongst the issues we are aware of.<p>One person who complains about something is one thing. Ten people complaining about the same thing that prevents them from working, that's another thing.<p>We have worked differently in the past. There have been changes to the company and changes in how product development is done. The business side of our company used to talk to the executives of the client company. We have been paid for all our products, whe have shipped them to spec, none of them is used, none of them can be reused, all of them left us with scars, and that way of working almost destroyed the company.<p>Fourth: everyone should be clear on what the team is doing, and what the team is <i>not</i> doing. This issue is not a priority. We will handle this one, this one, and this other one by this date. This part is handled by this person. Avoid the "I thought Alice was working on it".<p>Fifth: -good engineering practices go here-. Good test coverage. Patches get their tests, good commit messages, root cause analyses, and eventually knowledge base. A test harness is not "directly" good for the customers, but it gives confidence that you won't break everything. Loosely coupled, modular code: it allows for people to develop with different speeds and reduces dependency on unrelated parts, which is <i>really</i> frustrating.