1–10 of 124 posts
Do you let new customers drive your product roadmap, or just decide your own roadmap and stick with it? Which approach works best in order to gain more product velocity?
So let's assume you fall into the 10+ client category. The company should have a defined and published product roadmap that is being worked, new features should be vetted against the client demographic (e.g. it should benefit more then 50%, I usually set the bar higher early on like 80%) and if it passes that then it would be defined and put on the development schedule, but it should not disrupt the existing planned sprints on the roadmap. That means the client might have to wait to get this new feature, but the benefit is the product can be designed, kept reliable and stable and not get polluted with a bunch of make shift code and hacks. None of this has to be a crazy long process, it can be simple and quick and if sprints are 1-2 weeks, most likely many features can fit within the next 30-60-90 days at most (obviously assuming proper staffing etc).
The sales side of the business should never be in control of the development schedule, or product roadmap, it is a direct conflict of interest. Product management should be owned by an operations type person, CTO, COO but for sure a non-sales, and/or marketing focused person. This is what will make the company successful faster and help keep the product stable and on schedule. Founders when small have to wear many hats so they will be violating this all the time, but by the time they have hired a product manager, sales teams etc, the hacky crap has to stop if they want to succeed.
None of this means a client (or business) can't get a new feature turned around pretty quick, it just means that there is alignment of features to more than one client and that product stability, reliability and schedule are managed as first class problems. Startups struggle with this thinking it will slow things down, and they will lose deals, when in fact it speeds things up and makes everything more predictable. The key is requests can be done faster when the development teams can keep tech debt low and design things into the product properly. It also prevents the scrap it and rewrite it that happens when you don't plan well enough. To be fair, there is almost always 1-2 scrap code repositories early in the life of a startup, but it doesn't have to be that way, just usually works out that way because of people repeating preventable mistakes they haven't yet learned.
I do think it is important to recognize when you are first starting the company it is more free for all, scrappy and hacky, but even in those circumstances you should not be implementing features just because one client made a request.
Written meeting notes should be disseminated, and then corrected and augmented so that:
- 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)
- Those who were there realize they didn't hear/understand the same thing or plug holes. One catches what another has missed.
- 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.
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.
Include form to request a feature in the product itself. Directly from the users so there's no distortion. Everyone should get that issue.
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.
Add monitoring and analytics. We're working on that ourselves after putting out a lot of fires that looked the same.
Second: customers drive product roadmap in terms of raw data. Whenever users or customers ask something or raise an issue, ask yourself what is the underlying issue and what are they really trying to do. "Job to be done". Drill vs hole. Customers complaining is similar to patients complaining: they'll tell you about symptoms and then want you to fix those symptoms and they'll propose solutions and features. You gently take notes, and then dig deeper.
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.
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.
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.
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.
People demands and their behaviors are the solutions they have come up with to a problem. The problem is that they almost never tell you about the problem, 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.
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.
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.
Users would complain about something. We would notice a pattern. We would investigate, then figure out what to do.
They're doing two things:
- Exposing things we wouldn't have found
- Putting the finger on what hurts the most amongst the issues we are aware of.
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.
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.
Fourth: everyone should be clear on what the team is doing, and what the team is not 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".
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 really frustrating.
Reprioritization is good and normal, but decision makers need to understand the costs and a good roadmap allows you to communicate that better.
honestly the best tool i've ever used for this. and phenomenal software in general.
Just be very good at measuring and presenting data from all the channels in your company. Your customers, your prospective customers, your customer engineers, your sales people, your support team, your engineering managers, directly from developers too.
Understand the real cost of each feature. That's not easy. Try to predict the real value of each feature. That can be even harder. How many customers are asking for that feature? What's the avg LTV of that cohort? Will the feature reduce churn? By what percentage? Own those metrics and tell the whole company that's why you're prioritizing those specific features.
Be prepared to go back and check your assumptions and see if your predictions were correct...If you were wrong, then your next job is figuring out why and then working towards improving your own models to predict the value/cost of each feature. The fact is once you start intensely measuring that type of data, you'll find lots of gaps in your own process and fixing it as you go.
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…
There are multiple reasons for changing priorities.
Are there multiple business folks all generating requirements independently, insisting that their client is the most important? Get them all in a room to hash it out. Either they all agree on a ranking of the clients, or they each have to prioritize their own requests and choose a small number (say, 1-3) of truly critical requests to put into the engineering queue. If they can't agree on this, escalate to the CEO. If the CEO can't/won't prioritize, you're in bad shape. Your best bet is to make a judgment call as to which clients/features are truly critical and drop the rest on the floor. Be prepared to send out your resume if you make the wrong call.
If the clients themselves can't decide what they want, or can't communicate it effectively through the business team, you need face time with customers. If you have a product-minded engineer who is good at speaking the customer's language, include them too. The more direct exposure and intuition the engineering team has about what's really important, the more support you'll have in making those calls.
* Developer context switches are expensive (both in terms of developer happiness and productivity)
* Forks staying off main branch are expensive.
* Components/Modules being half-polished due to changing priorities are expensive (both in terms of customer satisfaction and introducing technical debt)
So for me, who is in a similar position, it's always a dance between what clients want, what management wants and what would keep my developers productive and happy and my product technical-debt-free.
If there's something that my clients ask for and it's really easy to implement, I would often ask my developers to drop other tasks and implement/hotfix it. But I'll try to redirect some good feedback from the customer side to the developer because I know they feel exhausted by changing direction.
A roadmap isn’t concrete. You haven’t mentioned if you use agile methodologies or not, but sprints can buy some breathing time and deliver progress.
Once a feature request made sense to the product to add universally, if it wasn’t too disruptive, and depending on the feature, I might let clients vote with extra dollars to move it up the backlog.
Sometimes, a feature was requested by enough clients that hey might even split the bill on a extra body to get it done.