We're a 20 ppl company in supply chain management and I'm leading the IT department with 2 ppl (+ outsourced development company).

For new features, in my ideal, imaginative world, the users would test real cases on the test system. After they've verified that everything is developed according to their needs, the developers could deploy the feature to the live system.

In reality,

  • people are super busy and don't want/have time to spend on a test system.
  • People are reluctant to changes and improvement and adoption is growing only slowly/gradually.
  • Use cases, that the IT hasn't thought of, will be discovered after the deployment to the live systems and need to be fixed on urgent/priority bases.

(side note: We're a small company, the team doesn't understand much IT and many are rather junior, so the CEO requires the CTO to understand the business processes and come up with solutions. We've tried involving the team in planning and idea generation but the outcome was rather poor.

side note 2: We're currently shifting from a waterfall pm to some methods of agile/scrum, but it's not a clean switch, rather a process and partial improvements.)

For new features (before deploying to live) I've done:

  • Recorded screen videos, explaining/demoing the new feature
  • Created user accounts in the test system for the key team members
  • Shared requirements and documentation during the planning phase with key team members
  • Created screen designs and wireframes to the team

but we keep on running into the issues mentioned about. Busy people, no contribution during the planning phase and fixes as well as change requests after deployment to live.

What can I do, to catch more use cases in the project planning phase? What can I do, to get people more involved early on in the development?

  • 1
    Hi Chris, welcome to this community. You might want to break the question down into two questions. 1) how to catch more use cases? (This question is linked to how the product fits into customer's life and i would suggest the usage of a Full Life Cycle Use Case), 2) how to get the team to test features early in the test system? (This clarifies you don't want to hire a specialized testing firm. It can be linked to the previous if we are using the product to determine the value). Sep 30, 2019 at 12:24
  • Who is "the team"? Do you mean developers - as in, developers are not currently writing and executing tests (considering both automated or manual)? Or do you mean someone else - internal users or stakeholders who validate the work?
    – Thomas Owens
    Sep 30, 2019 at 12:43
  • I don't know your company, but some thoughts: (1) Do you think realy all end users are reluctant to help? .. Maybe there are some still intrested. you need to identify them? (2) If people are super-busy: You want input from them. So ensure that they are offical team members of dev. team. Meaning that you can provide them a booking account for their extra hours. (3) Line manager of endusers need to support point(2).
    – BerndGit
    Mar 6, 2020 at 17:01

3 Answers 3


One thing I have found that really helps with engaging busy users is to schedule them in way in advance.

For example, I might ask them to make a 2-hour slot available every fortnight. This would be a recurring event in their calendar, so there is no reason why they should be unavailable. Discuss with the users what time slot best suits them (day of the week and what time during the day).

Then, build your development process around the user engagement slots. For example look to have a 'release' ready a day before a user engagement slot so that you have time to set it up on a test environment.


Tough spot. Short of a conversation with the CEO on hiring the right people to enable a digital transformation, I can offer an alternative solution.

Try to focus your efforts on solving pain points that the employees have. I'm sure there are many that may even be easy fixes. Showing the employees that you can make their lives easier will make them more motivated to give you time and help you further in the future. Try to prioritize fixing small pain points in the interim to gain trust and then move on to any of the strategic areas the CEO wants you to focus on.

From your comments, even scheduling some time to meet with people sounds like it may be difficult. This is where you may need to roll your sleeves up. Shadow the employees in their daily job, stay out of the way, but keep asking questions. You will learn what areas of pain to focus on, while being on their turf, so it won't seem like extra work for the employees. You will learn more about the business at a detailed level and will take the burden off the employees. Take this information you have learned to verbalize pain points and offer solutions.

I've recently worked with a CIO that has taken the approach of understanding the business at a detailed level and transforming jobs at a task level. Not an approach that I'm used to seeing from an executive, but in a certain type of environment, it can be successful.


I'm challenged with a similar question and try to face it with an example.

Nordstrom Innovation Lab

In this video they show, how direkt customer feedback leads to a more successful app since they only work on what customers value. How do they get the feedback? They work directly in a shop for one week and develop requirements and software along side.

Maybe you could convince your company to make a similar Lab? Focus one week on building something with direkt customer feedback and find out, how good this works for you? So you are not asking for a complete change process in the beginning but go in with as little effort as possible to validate your hypotheses. So you would make your on MVP in this case. At the end of the week you can make a retro comparing results to your normal way of working.

Your hypotheses is maybe not something like "In general direkt customer feedback helps to deliver better software" but "Direct feedback helps us to develop better software". Point out to your team that it's about them and try to mitigate their fear. With the first hypothesis you probably hear something like, "Maybe it works for a fancy team like Nordstrom, but it doesn't work for us." Can you prove them wrong?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.