I am doing a survey to find out from people the experience of working with a software company and their experience in whether the companies acted as good partners invested in your growth or did not show the attention your received. I am starting my own software development company focused heavily on a great customer experience and rapid delivery and any advice or experience notes would be of great help.
Here's a few problems I've had,
1. A lot of consulting firms use junior developers that you get to train up for them.
2. Senior people really meant the better junior developers.
3. Language barriers.
4. Time Zone, being on calls on a bad teleconf line at weird hours to people who barely speak English is painful.
5. Culture, not just company culture, see below.
Don't underestimate cultural problems, I've had several people who almost refuse to say no, they're "too nice" and take on unimportant work. There are cultures that find it hard to work with a woman. There are cultures where nepotism in the workplace is the norm, some places are so corrupt that getting anything done legally is almost impossible. There are cultures that will not work together no matter what's involved.
You can mitigate a lot of the above by paying more but the reason you're outsourcing something is to reduce costs :)
Johny, I've worked with with dozens of teams (foriegn and domestic) over the last 20+ years. My pain points have reduced as I have become better at my job and negotiating terms: 1) I always insist on minimum of 2 developers each workday (one works on dev and the other on bugs, backlog and QA) they load to pre-production and then I/we QA it, then they move it to production. Before I knew what I was doing I would always be a small fish trying to accomplish too much on the cheap. I always got behind bigger development jobs and things took much to long and I was always upset with the dev team.
Today I have found it's cheaper to put more and better resources into each Epic/Sprint. I was the problem most of the time in the past. I provided user stories and documentation that was much to sparse for the developers to do their job correctly. Today I start with a detailed PRD that is complete and delivered to dev prior to contracting, I also use Aha! and a prototyping tool (UXPin or JustInMind) to assure that I'm giving them exactly what they need, to understand what I'm trying to accomplish. I also have Jira integrated to Aha! so we have real-time insights as to where things are going off the rails.
My advice for devs is to be professional, don't take jobs from amateurs, insist on good documentation, spend a lot of time understanding the PRD prior to quoting the job or setting expectations with the client --And most importantly, talk with clients daily to eliminate the back and forth on QA and bug fixes. (I find most bugs are caused by me not providing clear instruction)
Hope this helps, call me if you want to chat.
Wasting too much time on refining the design and adding unnecessary features to the product. Failing to get valuable and quality feedbacks on product early on. It is always good to test as early as possible what problem we are trying to solve and for whom.
I like that you're doing this survey and asking the right questions. It's a step in the right direction.
I will be making suggestions from an employee perspective. I work for a Multinational, using lots of softwares as well as sell finished products. Customer is everything, hence developing customer friendly software/products and providing efficient back office support is key to excellent customer experience , retention and reduced churn.
1. Be sure to acquire modern technology and apply global best practice. It's expensive but it will keep you in business. Sometimes some development companies get fired for using substandard and not too recent technology. What happens? They will make loses and what if they borrowed money from the bank to facilitate their business.
2. Some Development companies in my opinion and observations engage cheap labour. Half-baked developers. Again this has to do with cost. As much as you do not want to spend so much on overheads, try to find a balance. Engage the right people from onset, it will reduce back and forth. Your delivery speed will increase and TAT improve.
3. The effect of no.2 above have ripple effects. Software users (employees ) and customers struggle with using software/products. You can trust that employees will provide feedback on software performance, efficiency and effectiveness and too bad if the development company is not doing much to bring software upto speed. As for customers, complaints and queries will have a long cue, some will ask for a change of product, refund and ultimately discourage other prospects.
4. Ensure to have experienced back office support and that they're customer-centric. I'm a Sales Person and I interact with customers daily. Your back office support must show empathy. Customer service training and retraining is very crucial. As a startup, you may not necessarily hire a pro to pay. You can source for those who can assist you train from your family and friends.
5.Pilot test: User Organisations will rush you to deliver software/products to meet their deadline and KPIs without doing pilot test. A selection of key stakeholders (user departments and customers) should test the product/software before launch/deployment. So that grey areas can be cleared, technical hitches sorted and answers to possible questions provided.
6. User Organisations should train staff on usage. In this digital age, employees can undergo product/software training right at their desk thereby eliminating cost of logistics. So why launch a product without adequate training of user departments or sales team?
7. Product Launch/software deployment: Employees and Stakeholders should be aware of product launch/software deployment at least one week before due date. Sometimes we get to know about a product launch less than 24hrs to the launch date and we have very significant role to play at the launch. Ensure that the user organisations properly plan and notify all stakeholders about the launch/deployment.
8. User organisations should make provision for demo products for their sales staff. Personally I like to be very professional in my sales engagements hence sometimes I have to buy some of the products to use them, understand them, identify possible questions to help my sales engagement. Not all employees will do that. So you can tell that not all customers will be very knowledgeable about how to use the products and have their questions answered.
9. Software/Product Brochure: this talks about the product and a list of Q&As to help users understand how to use the product.
10. Lastly; Always ask for feedback from time to time. Users can run development companies out of business.
In summary, from the outset, while negotiating with your client ensure to lay all cards on the table, get their buy in and name your price and have a documented SLA. You may lose some sales if you don't compromise quality/standards but you will remain in business if you stick to quality and maintain standard.
Hope any of the points will be helpful. I wish you the very best.
I run software development company in Gdańsk, Poland. I have 65 engineers and build every day MVPs for Startups. At the beginning, we struggled a lot with collecting requirements, preparing mockups, building correct backlogs just because founders do not really know what they need. Change has been everywhere and finally, we deliver late, out of scope and budget. Then we fully moved to Agile Software Development approach and all bad things disappear just with the month. We have been are working in this methodology for 10 years and I can say that I will never undertake Waterfall project this day. Of course, I raise money but my client will be suffering from bad product market fit (change is the only thing that happens constantly). Agile Methodology is key to be successful in this business. All the best, cross my fingers for your success.
i am working on development of a Management info system for BTL advertising industry. special MIS has never been developed before in the industry for media buying. i also started to market it but the main hurdle and a pain point that i have faced while marketing it is the adaptability of this creative MIS. even my MIS is 20 - 30 times faster than the traditional way but still advertisers do not adapt it that much easily. this is the thing i am facing a lot in creative technology introduction.
My biggest problem is before lunching any software I sign contract. As experience team to work.
This answer is way more complicated than may realize.
Is your customer ignorant of product development?
Many people who hire a development company have NO IDEA how to develop a product, and thanks to Dunning-Kruger effect, they don't know enough to know they don't know.
If it's an internal product, they probably don't understand their problem as well as they thing they do.
If it's an external product, they probably don't understand the customer's pain as well as they think they do. The hardest part is getting Product Market Fit. So that you build only what the user needs. No more. No less.
You can have a perfectly successful software dev company with uninformed customers who have you build products that fail, but I suspect you'll encounter some friction, and may be frustrated that you build things that never get used.
And in my prior life I was a consultant and noticed that customers didn't want to pay for stuff like "defining the problem". I called it a Conspiracy of Ignorance. They don't want to pay for that, and consultants didn't really want to do it. We all wanted to dive right into solving the problem.
I'd suggest interviewing them to see where they are with the above.
Bear in mind, that thousands of people have made the above mistakes.
If you can get the right kind of customer (who doesn't know the above but is smart enough to want to learn it) you could have a "course" that teaches them. It's a win-win. You establish authority, gain trust, and you get a better customer. It's like my dental hygienist teaching me to brush my teeth. (Sadly, I had to ask. Most people probably don't care about improving their brushing)
If your customer is actually knowledgeable:
If they understand the Pain they are solving and product development (unlikely!) then they are where I am, and here are the issues I've run into:
Problems I've had with developers (esp remote dev's):
1. Does not thoroughly read what I write. So they may ask unessary questions.
2. Or they may simply assume (either because I was vague or they didn't read).
3. They have poor UX skills, poor writing skills (can't write a good Button name -- it's not easy). A LOT of UX (in my experience) boils down to good written communication. The right name for a button. The right description, etc.
4. It's difficult to do rapid Hallway Usability Tests. If the goal is a happy end user then you get to cheat on the test: show it to end users as you go along. This can be done but it requres setting up a process in advance (have list of beta testers IN THAT MARKET group, good software for screen sharing, knowldgeable tester, etc. etc.)