We are writing an article "marketers vs. developers" and need developers to answer a couple of questions:
What are the main and the most importa...
For further actions, you may consider blocking this person and/or reporting abuse
Ok so even your title is wrong.
There is no such a thing that a "perfect" brief.
Trying to find the "perfect" anything causes a lot of stress, because there is not such a thing.
Simple hint: developers are really good at understanding other developers. Maybe search for developers who can write?
@jmfayard You might be misunderstanding Elena's goal here (granted, I might be too!). I think the use of the term "perfect" is a literary device for attracting attention to the article, to give readers the idea that, "Okay, this article might help me do much better at X".
The overall goal seems to be to improve communication between the people coming up with technical work to be done, and the people doing the technical work.
I get that she didn't make this to make me mad. And I'm not mad.
But I have the impression that she wants to connect with developers, and I wanted to warn her that right now she doesn't have the language and empathy to do so.
You're so right about needing to approach this with empathy and armed with the right language 💯
Engineers are often very pedantic, whether by nature or because of the nature of our work, and I know that for me attitude and word-choice have a big impact on how I respond to the information being presented to me.
It seems like in Elena's situation, the marketing team is preparing these project briefs, and I think it's safe to assume they have varying levels of technical background. How can we help them get better at presenting these briefs to us effectively?
I would be glad to tell it if it was possible.
But there is, in fact, no shortcut.
To develop empathy, they need to talk with and listen for a long time to real world developers.
Definitely agree there is no shortcut, I wasn't asking for one 👍 working together and imagining each other more complexly is the only way I know of to get better at approaching communication with empathy.
Hi, thanks for your answer! I do understand that there is no such thing as a perfect brief, but still, I believe there are problems and pain developers are ready to explain. And this can be used to make kind of a perfect brief ;)
So that's interesting, you understand that there cannot exist something like a perfect brief, but in the end you contradict yourself by saying that you could anyway make kind of a perfect brief.
Which one is it?
I will give you my understatement:
Your company doesn't understand developers and I don't think you can attract developers as long as you sound like marketers who are talking between themselves about developers.
Okay, I've heard you.
Quick question what do you mean by brief? Do you mean project brief on what is supposed to be done in a project?
I think regardless it might be as simple as "Keep It Simple Stupid".
As most developers might not be interested in the business aspects of it.
Instead they prefer it being to the point and specific on the topic is good.
Like for example I want my website to be pretty, easy to use & fast in speed.
This does not mean anything for us.
Unless you can produce the design, color schemes, fonts, icons, your marketing copy and size of the fonts with a few examples of how would you like it for the end product.
Hi!
Thanks for the answer :) Yeah, I mean project brief.
I am gonna make some assumptions about your context here, if they are wrong correct me plz and I will adjust my answer.
With these assumptions I will answer the questions:
What are the main and the most important things in the brief for the developer?
I would suggest follow some agile product management approach. With epics and user stories. Below I show an approach with user story.
Example
What is often forgotten to be included in the brief (something needed for further work)?
IMHO, It's that a project brief shouldn't be a set in stone. Generally speaking, a software project is an endeavour, so there isn't a clear path in most of the time, but by the interaction of the group with an open minded point of view its more feasible to achieve the results.
Business rules and restrictions, it's important make explicit what lines we are delimited. This can avoid future misunderstandings and frustrantion.
What is not as important but appears in brief?
All projects/stories prioritized as 'critical'. This shows no sense of what urgency really is. For this, I suggest check for product prioritization frameworks
How can marketers help developers with his/her work? What information to provide, how to set a task?
Avoid interruptions, developing is an intense abstraction exercise and the interruption can cost some hours to the developer return back to the stopped point.
Both marketers and developers should have an open mind avoiding preconcepts to work for the goal of the project.
Only developers set tasks, tasks are the smallest unit in a project and by their nature technical. Marketers should set stories and charge for them, not the tasks.
How do marketers interfere developers while thinking that they are being useful?
Asking for something that was not planned and prioritized.
Just a last comment, software projects are endeavours, and by this I mean its a constant change, it changes by context and time. Creating your article is a great start but putting in practice and then, reviewing your article it will create more value than just a first version.
I hope the answers help you =)
Hi Jackson, a helpful answer, thanks!
Thanks for asking, Elena! I love to see earnest attempts at improving communication within organizations ❤️
My first suggestion is that you avoid encouraging an "us vs. them" mentality, even in casual writing. It's true that developers respond well to certain presentation of information, but so does everyone 😄
Now, on to your larger set of questions. From the way you phrase certain things, it sounds like in your situation, the marketing team is responsible for communicating asks to the engineering team. Is that correct?
I've never been in that sort of situation: in the companies I have worked for, the requests pass through a product or project manager and are discussed and prioritized together with an engineering lead. But even still, I feel I can give decent feedback here.
In addition to a written document, I have always benefited from having a direct conversation about that document with the person(s) providing it. It gives everyone the opportunity to easily clarify any details and ask any questions that come to mind, and gives engineers the chance to adjust unrealistic expectations and correct any wrong assumptions in the document at the very beginning.
These conversations don't have to be long or formal: sometimes a 10 or 15-minute chat is all you need. The important thing is that the conversation happens at all, and that the engineers have been provided the brief at least two or three days in advance: depending on their workload, they may not be able to read through it right away.
Additionally, there should be no timeline or deadline given unless it has been agreed to by an engineering lead. This is very important; even time-sensitive/urgent requests need to be vetted by an engineer before committing to it. The only people qualified to provide a valid estimate for the work you want done are the people who will do it, so if an engineer says something will take 4 weeks, and you say, "Okay but the client needs this by X date," then you need to work with the client to either reduce the scope of the request or find a way to give the team the time they need to satisfy it. Remember, we're on the same team: we're not deliberately inflating our estimates to make your life harder! Attempting to force a timeline on an engineer only hurts your relationship with them and the quality of the work they can do for you.
What are the main and the most important things in the brief for the developer?
Once we have this information, I think most engineering teams can give you a quick and accurate estimate of how much work this actually is and our best guess at how long it will take to do everything. We can then work with you on fitting it into our product roadmap, reducing the scope of your ask and providing some alternatives if our estimates don't align with your needs.
What is often forgotten to be included in the brief (something needed for further work)?
In my experience, all of the things I listed above except "Goals." I often have to follow up to get that information.
What is not as important but appears in brief?
Mockups of the imagined result. A project brief is not a product design. Diagrams are great if they help illustrate your goals, but most of the time drawing mockups before discussing the request with your engineering team is likely to be wasted effort: projects are rarely so straightforward as to be able to accurately imagine the final result from the outset, and mockups in the brief can mislead engineers about what you actually care about.
Mockups are best deferred until later, once the work has been committed to and as one of the first steps in the project design.
How can marketers help developers with his/her work? What information to provide, how to set a task?
A great technique I've found is to create an online chat room / Slack channel dedicated to your request once it has been committed to, and prefer to have all discussions there. If any face-to-face conversations are had, summarize them in the channel immediately afterwards to preserve important outcomes and make sure you're all on the same page. This space becomes the "living source of truth" about the project, and is a fantastic resource during retrospectives.
How do marketers interfere developers while thinking that they are being useful?
Flooding our calendars with project-related meetings. Regular check-ins and demos can be useful, but they're not always necessary and often don't need to happen face to face or even in real time.
Remember that everyone uses a lot more jargon and terminology than they are aware of. When you're communicating with us, try to be conscious of your word choice and of the fact that terms may be shared between us but might mean very different things to each of us.
Oh, and please try to avoid using our jargon and terminology unless you're quite certain you're using it correctly (ask us if you're not sure! 😄): if we hear you use a technical term we might think you understand more than you actually do about something, which can lead to big communication issues!
Thank you, Daniel ;) You've helped much!