The Problem of Story Detail
The level of precision in stories is an industry-wide problem. In general, product managers want to convey high-level epics or scenarios while many developers want specific tasks. This represents a huge divide of expectations.
Often product owners or business analysts try breaking big ideas (i.e., epics) down into small user stories or job stories. An approach that many use is for product managers to design a prototype but that’s another form of specification. It’s true: you cannot program to an epic. But having product managers write specifications isn’t the solution either.
For example, your customers may want your screens to adopt their corporate look-and-feel—using their color scheme and logo on screens and reports. For a product manager, "adopt corporate look-and-feel” is a reasonable requirement. But developers often need to know more to begin working on tasks. Can we give them a color picker or do you want us to somehow fetch the color palette from their existing web site? Does that mean using the client’s logo instead of ours? Which file format do you need to support?
Who in your organization can answer these questions? Is it the product manager? the product owner? the dev lead?
My recommendation is that product managers own the problem (the "what") while the product team (developers and designers) own the solution (the "how"). Ideally, the team will discuss the problem in detail and propose a few solutions. The product manager will choose the appropriate solution based on his or her knowledge of the business and personas. But this idea is predicated on a cross-functional product team with experience. If you’re working with low-skilled programmers, someone—probably the product manager—will have to give them tasks.
How are you dealing with the problem of story detail? One technique that can help is to have a meeting with your team to discuss and practice story writing. In most cases the product managers want to provide less while the developers want more. Work on a few real examples from your product until you find the appropriate level that describes the problem but doesn't mandate a solution.