mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-29 21:41:00 +08:00
b8b48eca4b
sources/tech/20190718 How to apply -release early, release often- to build a better brand.md
111 lines
9.0 KiB
Markdown
111 lines
9.0 KiB
Markdown
[#]: collector: (lujun9972)
|
||
[#]: translator: ( )
|
||
[#]: reviewer: ( )
|
||
[#]: publisher: ( )
|
||
[#]: url: ( )
|
||
[#]: subject: (How to apply 'release early, release often' to build a better brand)
|
||
[#]: via: (https://opensource.com/article/19/7/build-better-brand)
|
||
[#]: author: (Alex Kimball https://opensource.com/users/alex-kimballhttps://opensource.com/users/marcobravo)
|
||
|
||
How to apply 'release early, release often' to build a better brand
|
||
======
|
||
Try this faster, more collaborative process to promote your project.
|
||
![][1]
|
||
|
||
The importance of open source—and specifically the maxim "release early, release often" (RERO)—can hardly be overstated.
|
||
|
||
This approach born at the command line has impacted the world as organizations of every shape and size discover what open, collaborative processes can do. Look around. The evidence is everywhere: on our phones, in our cars, in schools and hospitals.
|
||
|
||
If we still built software the way we used to, innovations across these and countless other areas may never have seen the light of day.
|
||
|
||
The worlds of marketing and brand development are no different. In today's fast-moving tech industry, marketers and strategists are taking a page out of the dev team's playbook, applying more agile methods to creating brand messaging and visual identities.
|
||
|
||
Why? For the same reasons cathedral-style development is no longer the best way to build apps: it's too isolated, too slow, and too disconnected from the reality of how the rest of the world works.
|
||
|
||
Fans of the TV series _Mad Men_ will be familiar with how marketing used to be done, especially within an agency. Marketing messages—taglines, slogans, jingles, and the like—developed by creative powerhouses with a unique gift they (and only they) seemed to truly understand.
|
||
|
||
A typical project would go something like this:
|
||
|
||
* The client hires the agency. Much excitement as the journey sets off; after a very brief introductory meeting, the client sends along a few existing materials.
|
||
* The agency retreats to its creative confines to wait for divine inspiration to strike.
|
||
* Many weeks and months later, the agency returns with—_**eureka!**_—the answer!
|
||
|
||
|
||
|
||
Why these antiquated processes don't work:
|
||
|
||
* They allow little room for the voice of the customer.
|
||
* They allow little room for the voice of those within the company who know it best and care about it most.
|
||
* They hold precious the final product until the very end, increasing the likelihood that bugs in the creative code will survive until it's too late. All destination. No journey.
|
||
|
||
|
||
|
||
That's not how today's most agile, most innovative companies build their software. It shouldn't be how they build their brands.
|
||
|
||
### 3 simple steps to begin your RERO journey
|
||
|
||
Applying RERO to your brand projects is simple. Start with these three steps:
|
||
|
||
#### 1\. Set clear expectations
|
||
|
||
As the well-known African proverb cautions: "If you want to go fast, go alone; if you want to go far, go together." When it comes to projects guided by RERO principles, setting clear expectations early can be the key to going farther, faster.
|
||
|
||
At any project's outset, gather your working team, partners, clients, or anyone else expected to contribute, and make sure everyone is prepared to adopt an agile mindset. Progress will be measured in speedy steps, not big leaps. In a room packed with perfectionists, some will likely bristle at this new approach—don't worry.
|
||
|
||
Don't forget the logistics, either. Share the project schedule, clearly outlining the milestones where all are expected to participate, as well as windows of working time where individual progress should be made.
|
||
|
||
#### 2\. Share silly first drafts
|
||
|
||
Ideas, especially rough ones, should be welcomed with open arms. We call these early explorations Silly First Drafts. The SFD is a crucial piece of our creative puzzle. Naming it makes it less scary. An open invitation to share with the team even the smallest seed of an idea without fear of ridicule or rejection.
|
||
|
||
Easier said than done, for sure. As a writer, I struggle to take this advice more than I'd care to admit. Putting something you've created out there before it's ready for primetime feels like a mortal sin. Not so in the RERO world. The goal of the SFD is to create more, more quickly — and get what you create in front of users and customers who can help you make it even better. To dive in, get messy and create in the open for more eyes to see and help improve.
|
||
|
||
Some content creators will bristle at this approach initially. Encourage them to embrace this discomfort with a more curious, growth-oriented mindset. Apply what the improv world calls a "Yes, and…" mindset, which emphasizes additive contributions not subtractive naysaying.
|
||
|
||
Emphasize the journey _and_ the destination. Not a simple binary of success or failure, but rather an opportunity for continuous development. At the project level, this approach helps combat progress-killing factors like the dreaded "paralysis by analysis." How much time have we all lost to hand-wringing indecision and over-thinking?
|
||
|
||
Gather input on anything you've created—whether lines of code or lines of copy—and your final product will thank you. Just make sure these "fresh eyes" know what to look for. Equip your team to understand how they can be most helpful. Highlight specific areas where feedback is most needed (and by contrast, where things are feeling pretty good).
|
||
|
||
#### 3\. Embrace technology
|
||
|
||
This last step is probably the easiest but worth mentioning, as it's overlooked more often than you might expect. Collaboration software has made life a lot easier for all of us lately and can be a crucial strategy to implement a RERO approach for your next project effectively.
|
||
|
||
##### Team communication
|
||
|
||
Today's crop of online messaging platforms is well-suited to match the pace of a RERO-guided process. Provide all project contributors—especially those who work remotely—with a single, always-available venue for productive discussions. For our money, the best open source option of the bunch is [Mattermost][2]. It does just about everything Slack can do—file sharing, real-time chat, robust integrations—while also letting you access the source code.
|
||
|
||
Set a few parameters for the team around best practices to keep the channel positive and productive. Without at least a few rules in place, channels and threads can quickly become side-tracked and GIF-overloaded. Describe the purpose of each channel when it's created so that everyone knows why it exists and what you're there to do.
|
||
|
||
##### Content creation
|
||
|
||
For content-related tasks that require word processing, spreadsheets, and presentations, open source alternatives to the Microsoft Office suite of products have been available for decades—chief among them was the now-defunct OpenOffice. Since its final release in 2011, a handful of other providers have picked up the torch.
|
||
|
||
LibreOffice is a good option, but by the development team's own admission, it may not be the best choice for enterprise deployments. For business-critical applications, check out [Collabora Online][3]. This hosted solution offers a full suite of office applications with powerful team tools for live collaborative editing, support for all major file formats, and data security protections.
|
||
|
||
With project files accessible to anyone with a modern browser, you won't have to worry about "I can't open it" issues that arise when your PC-loving executive goes to review work from the Mac-loving design team. And when revision histories are updated automatically, it's easy to revisit previous drafts and chronicle the journey you've taken.
|
||
|
||
Just be sure to set some ground rules as all your cooks enter the content kitchen at once. Allow one content creator to retain editing permissions while granting other team members comment-only or view-only permissions. This helps keep revisions to the core piece of content firmly within the realm of the person who created it and helps ensure all reviewers are reacting to the same version.
|
||
|
||
### How the future of business is built
|
||
|
||
Release early, release often is more relevant to our world than ever. This faster, more collaborative process is the way businesses of all kinds must create their futures.
|
||
|
||
Follow the steps outlined above, and you and your team will be well on your way to applying the principles of agile development, rapid iteration, and continuous innovation to your next brand development project.
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://opensource.com/article/19/7/build-better-brand
|
||
|
||
作者:[Alex Kimball][a]
|
||
选题:[lujun9972][b]
|
||
译者:[译者ID](https://github.com/译者ID)
|
||
校对:[校对者ID](https://github.com/校对者ID)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]: https://opensource.com/users/alex-kimballhttps://opensource.com/users/marcobravo
|
||
[b]: https://github.com/lujun9972
|
||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/branding_opensource_intersection.png?itok=4lf-f5NB
|
||
[2]: https://mattermost.com/
|
||
[3]: https://www.collaboraoffice.com/code/
|