The big promise, at least of the early agile movement was, to use a phrase attributed to Kent Beck, "healing the divide between development and business". This division had (and has) a negative impact, and therefore introducing it artifically in a "team of one" is to some extend, if not counterproductive, then at least pointless.
But, in your pursuit to deliberatly practice the business analyst/product owner/manager role, may I suggest to consider something that has become a bit of a lost art: writing up a software requirements specification in a more formal manner than "user stories". The story format originally was intended as a "promise for a future conversation" between people closely working together. A perferctly legitimate tool, albeit not as a replacement for a spec, and again a bit pointless in a team of one.
Here a few suggestions for skills/traits, that I could imagine, would make a product manager/business analyst, that many developers would be thrilled to work with:
Writing up good use cases, instead of "user stories". For example Alastair Cockburns "Writing effective use cases" is still a very good book on that subject.
Using the behaviour driven development approach to create an executable form of a specification
The concept of the "ubiquitous language" of the domain-driven design movement is something that I personally value greatly
Sketching UIs (and involving devs in the ideation phase)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The big promise, at least of the early agile movement was, to use a phrase attributed to Kent Beck, "healing the divide between development and business". This division had (and has) a negative impact, and therefore introducing it artifically in a "team of one" is to some extend, if not counterproductive, then at least pointless.
But, in your pursuit to deliberatly practice the business analyst/product owner/manager role, may I suggest to consider something that has become a bit of a lost art: writing up a software requirements specification in a more formal manner than "user stories". The story format originally was intended as a "promise for a future conversation" between people closely working together. A perferctly legitimate tool, albeit not as a replacement for a spec, and again a bit pointless in a team of one.
Here a few suggestions for skills/traits, that I could imagine, would make a product manager/business analyst, that many developers would be thrilled to work with: