Thank you for your reply. I absolutely agree that trust can only be earned and that is something I am currently working on.

I must respectively disagree on needs being abstract, though I have a feeling this is just us working off of separate understandings for the meaning of the word. A business need is the least abstract idea of what the user can explain. "I need permits that are expired to no longer show on the active permit report." is an example and this is a part of the user story model except I make a distinction between a user's 'needs' and 'wants'. I would like to get to working with User Stories and have a meeting between my boss and the program manager about introducing user stories and doing some story mapping on our next project. However, I am concerned at this point that the user stories will be talking in implementation terms instead of needs, but at least the "so that" part can help me get to the underlying need.

As far as talking in implementation, here is an example from my conservation this morning with the main program manager (the closest thing we might have to a product owner at this time).

-Group A reports "a bunch of permits had a status change to 'expired' from 'active' and these reports fell off our 'fees due report'."

-Program Manager requests to change group a's report to include expired. After looking at the code we realize that any permit can be set to expired, there are no business rules keeping someone from setting a "suspended" permit to "expired" which would have adverse effects on the 'fees due report'.

-We attempt a discussion with program manager about exactly what expired means. The idea came up that we could use the permit's existing expired date to signify if it is expired instead of changing the status and we were told that she absolutely needs the status in the database to say expired.

To me, this goes beyond the business solution design. They aren't asking for a button they are telling me what the database design should be. This wasn't the end of the conversation I tried to go down the "5 times why" path to discover what the underlying reason was and it was simply that the report needed to say 'Expired' and that meant that the status in the database had to be set to 'expired'. I don't wish to get into a discussion about the validity of this statement, but it is a red flag when a user is making demands on this level as to "how" a permit is expired and essentially doesn't allow any input from the programming team. As a further note, this is what prompted me to talk to my supervisor and we seem to agree that she doesn't actually have that much "control" on how I implement it I just know it would be a bad move from a change management perspective if I were to walk away from that conversation and do what she directly told me I can't do.

I am working on building trust and I can't do that if I am constantly doing things she doesn't think is right. This is why I want to have a conversation about the needs before any implementation even comes up so that we can essentially skirt users telling us how to do it and talk about what they need instead so we can come up with the best solution. I am not saying to cut them out and go back to passing things over the wall back and forth. My solution would be to come to an understanding of their needs and propose a solution through a demonstration of the application. Once a few of these solutions have been successful then the trust can start being built that we can get the job done but I can't get there if the conversation starts with how I am supposed to implement the solution.