

Ask HN: how can I brief my devs better as non-tech founder?  - rafweverbergh

I&#x27;m a non tech founder working with outside developers (at least until product market fit).<p>I&#x27;m mostly doing fine with briefings, but occasionally the developers misunderstand how certain roles and permissions interact.<p>I found an article about &quot;Actor-Role Patterns&quot;, which seems like interesting stuff but which is also too advanced for me to create briefings based on it.<p>Ideally, I would provide my developers with a very clear diagram of what the entire application is supposed to do. The problem is: I have no idea where to begin looking.<p>You would help me tremendously by throwing me some breadcrumbs. Thank you in advance!
======
RollAHardSix
You need to pick up pen and paper and create diagrams and flowcharts, if you
can't chart it out, it probably doesn't make any sense. If you get confused,
grab your senior developer and explain to him one on one what you are trying
to achieve. It doesn't matter that you are a non-tech founder, your working
with developers, you need to adapt your processes to how developers think and
work.

Bullet-points work great and provide easy references to things like intended
file-names, and also provide an easy way to break down a conditional
statement.

You need to look into psuedo-code, because in a way, that's what you're
looking to provide. Otherwise, you might as well just give the developers and
the client a one on one and get out of the way. You have to be providing
something that makes the developers life easier then handling all the
interaction themselves and that something provided has to be something other
than just time.

We need to understand the purpose of the system, how it works into the overall
program, how it should look, how it should feel, intended program flow,
intended results, we need to know a lot of everything not a little of
everything.

You also need to be almost constantly available to answer a quick question.
There are just too many issues that may crop up while working on a program,
case in point I was working on a project earlier today which featured two
different types of an overall master type inside a record of a database. I
made a (highly educated) assumption of which type I was using based on context
but I could have been wrong. Knowing which sub-type to use was something that
wasn't available to me immediately with the information I had on hand and
didn't appear to be an issue during our requirements meeting, it only popped
up when I was re-checking program flow, specifically error catching. These
little things can happen all the time, and the only real way to beat them is
communication.

~~~
rafweverbergh
Thanks for this input.

------
sharemywin
Not real familiar with the term briefing? but if you mean like a requirements
meeting. uses cases are pretty useful:

[http://en.wikipedia.org/wiki/Use_case](http://en.wikipedia.org/wiki/Use_case)

There's also interaction diagrams and state diagrams depending on the type of
software your using.

~~~
rafweverbergh
A "briefing" is a term from advertising & PR agencies. It is a document in
which the customer explains what their business context, goals and "value
demand" is, at what budget etc etc.

Thanks for the link, I will look into it. I worked with use cases and user
stories, but user stories will frequently have some gaps in them - and it's in
those gaps that misunderstandings occur. I was hoping that there's a universal
language to create bullet proof models.

~~~
georgemcbay
"create bullet proof models"

Assuming that is possible (for anything but the most simplistic of systems) is
likely the root of your problem.

~~~
rafweverbergh
I thought this might be ambitious, yes. Although at this time the system is
(still) really quite simple.

Also, I thought: there must be a better way than saying: "So when user A logs
in and merges records X and Y, user B will see the changes but not user C
because he's not an admin".

But apparently I am mistaken?

~~~
RollAHardSix
I'd wager you just aren't being clear enough. From what you just said, I have
zero context as to why user B can see those changes. I can make a guess,
because he's an admin, but it's just that, a guess based on the little context
you provided about user C not being an admin and being unable to see the
changes.

