What’s the point of going to conferences?

by Hanna Cevik

We have a £2,000 annual training budget at Red Badger that can be used however we like. Most people use it to travel to attend a conference in the US, Asia-Pacific or somewhere equally exciting. Training is really specific to your job role and expanding / honing your skills though, so sometimes the most relevant conference is… at the London ExCel.

On 12th May, I took myself out to deepest, darkest docklands (admittedly in my MX5 with the roof down as it was a super sunny day) and wandered around hall S6 for 7 hours. Amongst the stuff I wanted to hear about was why buyer journeys are all wrong and how to speak to big prospects whilst still sounding like a human being.

At Red Badger, it’s really important to us that we talk sense, both in terms of what we do and how we tell you about it. I was keen to hear how other people did it, and what the audience thought about it. One of the things I love about how we build new business here is that we don’t have a sales team. It means that we find new business based on our reputation, the need of the client and our suitability to do the job, not because someone wants to meet their target and get their bonus. Many agencies do use that model and it leads to division internally; projects teams hate the sales team because they just throw projects over the fence and don’t care about how it’s been sold. The clients are almost always disappointed too; they end up having their projects de-scoped to make them possible in the time or for the price they’ve been promised.


What are you doing right now?

We don’t work like that at Red Badger. Ever. We are one team from pre-sale conversations to support; you’re always talking to people who know and respect each other’s working practices and understand how and why something has been designed or built that way. As a marketer, it is a joy to work with.

The speaker in the “Maximising your Business Relationships” session talked about how he felt the same disillusionment with that model, and set out to prove that large projects could be sold and managed without resorting to sales speak. This actually makes life a lot easier for both the seller and buyer. The pressure to talk in acronyms and business language can make it really hard to know what the other party means or wants. It’s a lot easier to say “I’m going to provide you with some recommendations to help get everyone on board” than saying “we realise this is going to be a c-suite decision, and I will provide you with a formal RfP response via procurement”. You have the same obligations to meet due diligence but everyone feels like they are dealing with another human person. There were murmurs of uncertainty in the room; “but how will we sound important and knowledgable without using all those buzzwords?” – and frankly that is exactly the problem. If you don’t know how to sell your product without being plain and transparent, it’s probably not the sales process that is flawed.

It’s a lot like the Agile/ Lean process itself – cut the waste, cooperate constantly, deliver fast. Endless documentation (e.g. large proposal documents) doesn’t get anything done faster, and may well add to losing sight of the end goal. Just like when you propose Agile, lots of people in the room looked worried. It’s hard to let go of the models you’ve been using for years. But that’s exactly why you should do – they are obsolete. Just like the monolithic agency giants – they no longer provide the best solution.

It tied in with the buyer journeys talk I’d heard earlier in the day. If you are using the ‘traditional’ sales funnel, you’re going to be disappointed with your conversions.

sales funnel

This is just not how it works anymore. Most of your prospects simply aren’t interested in hearing about how your solution is going to do something X times better and Y times cheaper than your competitors over 40 pages of sales documentation. They want to know what it’s going to be like to work with you and how that is going to get the result they need delivered. They want to know why they should work with your teams, specifically, to achieve their aims. The old sales funnel model focuses too much on saying the right thing to the prospect to get them ‘down the funnel’, when you should be focusing on how to solve their issues.

Going to conferences isn’t always about learning new skills, sometimes it’s about being given the confidence to let go of old habits. Knowing that sales-speak isn’t necessary, that doing the right thing is more important than saying the buzzwords and being bold in your decisions will mean that you don’t make the same mistakes as before, and get a different, better result.

So, thanks B2B Marketing Expo! You reminded me that doing my job well is often about simply treating people as human beings.


Lean UX Workshop with Jeff Gothelf – My top takeaways

by Sasha Ward

Last month I enjoyed a trip down to Brighton for a day long workshop with the author of Lean UX, Jeff Gothelf. UX enthusiasts from across the UK and some from as far as Sweden came down to the south of England to learn more about Lean, UX and all things in-between.

I’m going to run through my top takeaways from the workshop and explain how they can be applied within your product teams.

1.Don’t solve problems that don’t exist

It’s a waste of time, money and resources making solutions for problems that don’t exist. How do you know if a problem actually is a problem? Well, get out of the building (GOOB), talk to your users, ask them about their problems and observe their current behaviours or current workarounds. They might be happy with their current solution but you won’t know until you talk to them.



Within your team, get together and write down your assumptions of what you think the problem is and create a problem statement that you all agree on (you can use a problem statement template – see Jeff Gothelf Lean UX).

2.Focus on the ‘M’ in Minimum Viable Product (MVP)?

Every organisation, every team will have a different opinion of what an MVP is, “a stripped back version of the final product”, “our must have features”, “version 1″ the list goes on…

What Jeff helped cement in my mind about MVPs was two things:

– that MVPs are for learning, not basic versions of the “final” product
– and they’re not restricted to digital means

Think of MVP’s as tests or experiments to gauge interest/viability of a certain feature or product. The first question to ask yourself is “what are you trying to learn?”, then ask yourself “how can we learn that by doing the smallest amount possible?”. At this point don’t be restricted by thinking that you can only learn by shipping a basic version of the final product. What you can do instead is leverage existing technologies/services/products in order to create an experiment to test your hypothesis by using methods like landing page tests, feature fakes or wizard of oz/concierge tests.

It’s important to set a threshold for success when creating  your MVP, e.g. when we see more than 100 clicks per day on this feature we know it is worthwhile to continue with this, or if 1000 people subscribe on our landing page test in the first week we will know we are successful. If you’re not clear upfront what what success looks like then how will you know when to stop the experiment?

3.Write tactical hypothesis statements

A hypothesis is a hunch, it’s our best guess of what we believe to be true. They are a great place to start when at the beginning of building a new product or feature, but remember they are still our assumptions so they need thorough validation.

They are quite tricky to get right as a good hypothesis statement is made up of a lot of variables with a lot of assumptions baked into them. They are usually comprised of a KPI or success metric, a persona, a user goal and a feature.

Jeff Gothelf has a great template in his book Lean UX that combines them all in a succinct way:

– We believe will will achieve [KPI] if [persona] will attain [user goal] with [feature].

The most valuable lesson I learnt from the workshop was to be tactical about how you write these, think about what is in your control and think about what you are trying to learn. If something isn’t in your control then don’t go ahead with it, have a rethink and move forward swiftly.

4.Start learning more

What I mean by this is, add stories to  your product backlog purely aimed at learning something or running an experiment. Treat learnings the same as you treat other user stories and get your team invested in learning more.

These can be treated in the same way as regular user stories, scope them, define the problem, write a hypothesis and go out and test it. In doing so you are likely to learn something you didn’t know before and it’s good practice at getting everyone in your team involved in the collaborative exercise of writing hypothesis statements and creating MVPs.

5.Getting buy-in to Lean UX in the enterprise

This was a topic that had a lot of interest from the attendees of the workshop and the best pieces of advice was to speak the language of the people you are trying to convince to buy-in to Lean UX and in doing so try to bring them closer to the process.

There is a lot of technical jargon that gets thrown around day-to-day and understandably it can be quite off-putting and intimidating. What’s important when trying to get buy-in to Lean UX in the enterprise is to speak the same language as the stakeholders and understand what they value. If their interests are in acquisition and conversion, then speak to them in this terminology, don’t start talking about progressive enhancement or typeahead as this will only cause more confusion and more unproductive conversations.

In summary…

We all aim to create great products that people need, and Lean UX provides us with guidelines to help move teams from doubt (assumptions) to certainty through evidence based decision making. As the UXer, start by getting your team on the same page by facilitating hypothesis workshops and design studios to help identify the problem and create actionable hypotheses that you want to validate through testing. You and your team will learn every time you speak to or test prototypes on your users so make sure you do this as frequent and early on in the process as possible, seeing as these are the people that you are designing for you need to create a dialogue with them as often as possible to ensure that you are on the right track.

1. Lean UX – Jeff Gothelf- http://www.jeffgothelf.com/blog/lean-ux-book/#sthash.Y6ULPslO.qI01GYOY.dpbs
2. Popcorn hoodie – http://www.ohgizmo.com/wp-content/uploads/2013/02/Pop-corn-hoodie.jpg
3. Feature fakes – https://www.industriallogic.com/blog/fast-frugal-learning-with-a-feature-fake/
4. Wizard of oz/concierge tests – http://www.usabilityfirst.com/glossary/wizard-of-oz-prototype/

This is only a brief summary of some of the things we covered throughout the day so if you’ve got any questions then please get in touch on twitter or comment below.


Badger Slack Digest – May 2016 issue

by Alex Savin


Selected bits of shared information from our private Slack channels at Red Badger. Grouped by channel names.




    • Gitsome – A Supercharged Git/Shell Autocompleter with GitHub Integration.
    • JavaPoly.js – a library that polyfills native JVM support in the browser. It allows you to import your existing Java code, and invoke the code directly from Javascript.
    • Mocha Trumpet Reporter – display a trumpet and make authentic sound when your mocha tests fail. Get a microwave ding when everything is green









  • Reasons.to Design, Code, Create & Come Together – Brighton, UK; Sept 5-7 2016
  • Strange Loop St. Louis, Sept 15-17th, 2016
  • PolyConf – Poznan, PL; Jun 30 – July 02 2016
  • From The Front 15th and 16th September — Bologna, Italy
  • EuroClojure – Bratislava, Slovakia; October 25-26

Bonus track


React Amsterdam – a few quick takeaways

by Alex Savin


This was my first React dedicated conference, and to be honest I had my reservations. There is only so much you can fit into a single topic. One day single track conf turned out to be quite diverse to keep the attention all the way. As usual I was keeping random notes from the event. All notes and ideas are originated from talks, but are not necessarily direct quotes.


React Native

If you always wanted to try RN but were afraid of the tools and setup you have to do prior to writing a single line of code, fear no more. There is a service that allows you to write and run native iOS/Android apps in browser as you type. Basically, JSBin for React Native. Meet rnplay.org. It also allows you to switch and try apps on your actual native device.

Behind the scenes there is Appetize.io service that streams iOS or Android simulator directly into your browser. As far as I know there are no real devices involved, but native simulation is a great start. In fact, React Native official documentation now uses the very same embedded simulation for illustrating the examples. Go ahead, run some native iOS apps in your browser.


Tinker. Release. Repeat.

Another interesting initiative is React Native Package Manager – RNPM. Managing modules with native dependencies is not easy at the moment, and RNPM is here to help. There are rumours that it might even be included as part of RN offering (and it is already mentioned in the official RN documentations as a preferred way of linking).


JSS builds on top of  @Vjeux‘s idea that you can specify CSS properties of HTML elements as part of JSX declaration (which compiles into JS). The original approach lacks quite a few things like media queries and pseudo classes support. Christopher himself said that you should use common sense and combine inline CSS in JSX with conventional stylesheets.

Not anymore. JSS supports all CSS properties, can easily be used with React components, or simply compiled into CSS. It also offers dead code elimination, name scoping, rule isolation and fast selectors. It is even claimed to be faster than conventional CSS. And if you like idea of plugins, it has them too. The selection is far from PostCSS plugins catalog, but give it time and some crayons.

Apollo by Meteor

GraphQL is a great way of communicating data from backend to clients. It also requires a bit of setup. It is just a language, as a developer you will have to implement server side and client side support. On a server side it is likely that you’d use GraphQL layer as an opportunity to unify multiple RESTful (or otherwise) endpoints into a single GraphQL API. On a client you would in turn create and consume GraphQL requests either directly, or with something like Facebook Relay.

This is where the Apollo project steps in. Apollo server helps you consolidate multiple data sources into a single GraphQL endpoint. Apollo client help’s you to consume that endpoint, provide pagination, reactivity and optimistic UI updates.

Both are still very much in development and not really ready for prime time. There isn’t even much details on how exactly it’ll work.


Recent tweet by Dan Abramov

MobX (former Mobservable) allows you to observe changes in things and act when those changes are happening. It uses ES6 decorators to help you wrap existing things (like app state and React components) into observables and computables. Observables are things that are being watched for changes. Computables are the things that must be updated as a result of a change.

If you choose so, MobX can be used as a Redux alternative. Like Redux, it promotes pure functions and is built on Functional Reactive Programming principles (FRP). You define observables and things that can change as a result, and then sit and watch how things are happening automatically.

There is pretty good 10 min MobX interactive tutorial available for playing.

Tweet Cube


A cube that projects tweets. Bonus for the cat userpics.

It would be a perfect companion to the throwable cube mic.


The place was called Pllek. From the official description:

This post-industrial spot with a beach-like atmosphere offers one of the best panoramic views of the IJ River… Pllek also is home to Amsterdam’s largest disco ball at night.

To get there you cross the IJ river on a ferry from Amsterdam Centraal station. The place is pretty bizarre, with a rusting Soviet submarine in the bay, cranes, sea containers and a chilly wind. I even made a short film on getting there and back.

I get the feeling that organisers didn’t expect the weather to be so cold in the mid April – it was pretty chilly inside. There were lots of developers from Netherlands, but also from all over the Europe. It was a chilly, crowded, but very friendly event with nice snacks and coffee. It was also first of a kind, and they do intend to continue next year.



Chilly weather didn’t affect popularity of the (free) ice cream stand



This trip was possible thanks to Red Badger’s learning budget perk. Join us, and you’ll get it too!


London React Meetup – April 2016

by Leon Hewitt

An evening of testing workflows and dynamically built forms awaited visitors to Code Node last Wednesday when the London React Meetup was once again in town.

Tom Duncalf kicked things off by describing what he has found to be effective unit and integration testing strategies for React applications.

Tom explained his rationale for writing tests and in particular unit tests. In addition to verifying the application behaves as expected and providing a useful set of automated regression tests (allowing you to refactor with confidence), he pointed out how well written tests can act as documentation for the code and enable faster debugging with less dependency on end-to-end tests (be they automated or manual) to expose errors.

Taking this testing philosophy, Tom went on to discuss how this applies to testing applications built with React and listed the qualities he looks to test in his components (e.g. do they render correctly, can you interact with them as expected and how do the integrate with the rest of the application).

The talk was full of code examples of how Tom went about implementing his tests using his toolchain of choice: Mocha, Chai and Enzyme.

Next up was Anna Doubkova discussing her experiences with Redux Form and how useful it was in developing a CMS application she was involved in with her team here at Red Badger. One aim of the project was to deliver a CMS with less dependency on developer input to extend. Anna noted how great it would be for the customer to alter their CMS just by changing the data structure. i.e. have fields added by the CMS administrator automatically render on the page without the need to bring the development team in.

A combination of JSON SchemaRedux Form and React enabled the team to do just that. Anna took us through the journey of developing the solution and the reasons for the technical choices made.

Anna ended by listing the pros and cons of working with redux form, expressing overall how easy the team found it to use.

Rounding the evening off was Arnaud Rinquin who shared his journey of reducing the friction he was feeling around testing in the javascript ecosystem. It’s no secret that the toolchain takes a bit of setting up, leading to developers experiencing what has been politely termed Javascript Fatigue.

Inspired by Dan Abramov’s Redux tutorial,  Arnaud aimed to recreate the feel of Dan’s environment in his own workspace. That being: run the tests in the browser, have tests alongside the production code (in the same file), have the tests run automatically on a code change and have the tests execute in the shell  (to facilitate continuous integration).

He successfully achieved this through a combination of a babel plugin (to remove the test code and any dependencies from the code files) and a specially written chrome plugin (to control the test runs). This achievement has enabled Arnaud to enjoy what is for him “a proper TDD workflow”. He can now keep coding and stop worrying.

The success of these meetups (all the 300 tickets for this event were snapped up within an hour) demonstrates the popularity of React in the London software community and the quality of the talks highlights how open the React community is to exploring and embracing new techniques. Everyone’s already looking forward to what fresh insights May’s meetup will provide.

Hear about when new events are announced first by joining the meetup group here.



There are two kinds of websites, which one are you designing?

by Clementine Brown


Somehow, in the fast-paced world of our many, many Red Badger Slack channels, I managed to accidentally accept an invitation to talk on a panel.

So, at an event hosted by inVision, in an very large building in Bishopsgate, I found myself flanked (stage left to right) by the Head of Design for Disney Labs, Lead Designer for BBC Worldwide (little old me) Head of Design for GDS, and the Creative Director of Lagom Magazine – talking to 400 people about Design+Ethics.

We were asked a lot of questions. Everyone said some interesting things. So over the course of a few blog posts I’m going to outline some of the issues we covered, and some of the debates that could come out of it. And maybe you’ll have some of those conversations around the water cooler.

Hey, I drew that!

I’m going to start with one of the questions that interests me the most, which was broadly addressing the issue of websites looking the same – and whether there is a line a designer can cross between design inspiration and design theft?

What happens if you see something you’ve designed re-used, and repurposed, with someone else’s name on it? A difficult question, but luckily one I don’t really have to think about. Because I’m a consultant, I spend a lot of my time either starting design work, or putting my sticky little mitts in the middle of work that’s already on the go. Rarely am I a finisher.

But when you think of this in terms of the web – who really owns the idea of the burger nav? Who owns the 3 column pattern? Who owns the concept of a hero image? If these are used over and over again, is it imitation, or is it in fact some kind of hive-mind-design-pattern? And should we be reframing the question, to ask instead what our ethical responsibility is to *make* things the same? If you think of “the typical website”, what comes to mind? That’s right, a full-width image with an H1 overlaid, then 3 columns of info, then perhaps a portfolio element. It’s not the most inspiring, but one thing you can be sure of – most users will understand it, know where to look for the content they want, and it will work on their phone. And for the most part, that’s all users care about. Simplicity and patterns win.

During the conversation, Ed Fairman (lead design at BBC worldwide) said that as a community, designers are proud of sharing ideas, of sharing work – and I think accept with that the probability of someone else using the theory or application in their own work. Now these systems are established, the challenge is for designers to do their own thing within them.

There are only a certain amount of ways to design a product and it remain effective. At one point Louise Downe asked the audience “who actually enjoys novel things on the internet?” and the result was, well, underwhelming. It turns out that not many people like novel things on the internet – and I expect those who do only do when they’re browsing around, and if they were looking for a something specific like, say, the etymology of the word “kangaroo”, I’m reasonably sure they’d be annoyed if a silhouette of Rolf Harris singing ‘Tie me Kangaroo Down Sport’ scrolled across the screen (what? I’d say that’s pretty novel). I think that this similarity of design is in fact a reflection of what users expect from a website, and of designers and UXers listening. So, from whence else does this similarity spring forth?

Fork it

Think for a moment about a fork. They’ve been around for quite a while (according to Wikipedia, the earliest one found is dated to be 2400 BC). They may have ‘evolved’ by being made of different materials, but, fundamentally, the way we use forks has remained the same, and so the design of a fork has remained the same. Not so with the web. With the proliferation of tablet and mobile devices, and their increased internet connectivity (you could even read this blog while being 190 feet underground on the tube, for crying out loud) the demands on a website have changed. We’re using it in different circumstances, in different ways, and to do different things.

At the moment the design trend is big, bold, flat, simple. Many may think this comes at the whim of some group of self-proclaimed superstar-ninja-design-prophets (my mother, to this day, refuses to upgrade above iOS6 because “why would I want something that looks like it’s been designed by a child?”) But really, this trend is (in part) down to the limitations of our fat little fingers. As web traffic from mobile devices is increasing every day, so is the knowledge that soon having a touch-unfriendly site will no longer be an option. Big bold buttons, card-based design (more clickable area!), boxy layouts and easy column hierarchy are all resultants of touch-based interactions, and so naturally that has impacted on the aesthetic. 

The skeuomorphic approach of the likes of my mother’s favoured iOS6 has disappeared from new web designs, not just because of the ‘modern look’ or touch screen constraints – it also had an impact on page load time. Heavy graphics and large css files meant that users on a slower mobile network had a significantly low-grade experience compared to those on a newer device who paid for 4G – and that is an unnecessary separation. As designers and developers in this new era of on-the-go browsing, we have a responsibility to make sure the content and information a website provides is available in the same way to anyone who chooses to look at it.

Don’t make me screen

Designers are excited about this, because responsive design allows us to make the most of our screens. In the early (and not that long ago) days of mobile design, the very term ‘mobile design’ meant literally designing for a mobile phone. So you would design two versions of the website – one for computers and one for phones. There was no in-between. As technology has evolved, so has design – it’s simply unsustainable to design a version of the same site for each device that we can view it on – especially as now those range from the 1.4 inch Apple watch to the 88 inch 4k TV.

With HTML5, JavaScript, CSS transitions, standards compliances for browsers, and users increasingly becoming creators, the internet is no longer a place for the few to build and the many to browse. People are more interested than ever in having their own space, creating, uploading and sharing their own content – and with this interest has come the evolution of frameworks. With no design or code knowledge, people can not only create their own website in a matter of hours, they can create a site that other people understand how to use. This is because all the big frameworks (think Bootstrap, Foundation, Squarespace etc) have all used a standard pattern that has become recognisable on the web. As this shared language of interaction becomes more widespread, so the internet will become more accessible and intuitive.

At one point Elliot Jay Stocks asked and answered “What value does bespoke work bring?” The answer was a deeper understanding of the medium. So we now have to address how we navigate this frameworked, patterned landscape, where we have these design systems that are common, but are also expected to create something novel. As a designer creating a web space for a client’s content to be showcased, I think we have a responsibility to do that in a recognisable, effective and frictionless way. And at the moment that means gradually defining patterns and encouraging behaviours that are relatable and effortless.

Fancy being part of our team? Head over here to check out our Digital Designer job spec!


Characteristic of a Good Product Owner

by Toqir Khalid

Typically on most Agile projects, the success (or failure) of a project can heavily depend on how good (or bad) the product owner is and how committed they are. Good Agile teams that consistently deliver the right thing at the right time, and with quality in mind, will always have a product owner that is focused on the overall bigger picture and able to articulate this into the smaller pieces that are needed to deliver their vision/goal – i.e. the individual user stories.

Anyone can take on the role of the product owner, but to be a great one is hard! Let’s take a look at some characteristics that great product owner’s have:

Relating the vision/goal to backlog items

A lot of product owners are good at making the business case for a project to go ahead, but very quickly end up with a backlog that is disjointed and seems disconnected from the original vision/goal that they started with. After a couple of sprints, it’s likely that most of the team (perhaps they too) have forgotten what the original goal was and why they’re doing the project. The phrase ‘can’t see the forest for the trees’ comes to mind.

A great product owner will

  • ensure the business case is encompassed into a short vision statement,
  • makes this visible to everybody.
  • But more importantly, can always refer back to this when explaining every user story on the backlog.

One of the best ways to convey your vision/goal is with an elevator pitch. The product owner should

  • come up with their elevator pitch,
  • make it clearly visible to the team,
  • and constantly refer back to this to explain why the team is working on the prioritised backlog and the individual user stories.

Write User Stories with the team and allow them to contribute to the business value, i.e. the ‘So that…’

Often product backlogs are created by the product owner in silo and given to development teams. A lot of the time, the user stories are a set of task lists (or wish lists) the product owner wants the team to do. It can be difficult for the team to understand why they’re doing what they’re doing, especially if the vision hasn’t been stated.

A great product owner will

  • work with the team to come up with a product backlog that is
    • relevant,
    • links back to the vision,
    • but also includes the business value (i.e. the so that …).

This means the team fully understands the reasons and value of each user story and how it is intrinsically linked back to the vision.

The product owner must ensure that each user story has

  • a clear ‘why’ for each user story which explains the value/goal for the user
  • what the user is trying to accomplish rather than the feature in the system.

A great product owner will try to work with the team to solve the problem/issue for the user. This is likely to allow the team to solve the problem in a way any individual wouldn’t have thought of doing.

Respond to changing circumstances

For the duration of a project, business goals, technology changes, new regulations, or a competitor’s latest release will likely mean that the business/project priorities need to be changed in order to adapt. Often product owners and senior management will try to stick to the original goal in the hope that they will be seen as correct. Often that is not the case, and the project ends up delivering something that is out of date before it’s even launched.

Product owners should

  • always be able to adapt to changing circumstances
  • and modify the current product backlog so that it’s inline with what’s current now.

The modern world moves at a rapid pace, and great product owners are able to ride the wave and change the product backlog accordingly without having to throw away lots of work.

In order to do this, the product owner and the team should only be looking a couple of sprints ahead. The top of the product backlog should contain user stories that are small enough and have the necessary details that the team feels comfortable with. It’s very hard to see past a couple of weeks, as things are likely to change, so why plan to detail product backlog items that are planned for several months into the future. Simply add Epics/Themes to the backlog which can be elaborated upon when the time is right

Backlog priority

Say No without being a jerk

Senior stakeholders trust product owners to make the right decisions for the product that is being built. Therefore, a product owner must be conscious of what they say yes or no to. Great product owners will say no to many requests without being a jerk. The following are some examples a product owner could use:

  • ‘Thats a good idea, but we’d need to pull something out from the current backlog to accommodate this. What would you suggest?’
  • ‘Can you help me understand why this is important for you. Maybe there’s another way to solve your problem and we might have something similar already on the backlog’
  • ‘Maybe we could include that as part of this story, which is similar?’
  • ‘I”m not sure that aligns with the current vision for the product/project’
  • ‘No, because [reason why you’re not putting the item onto the product backlog]’

It’s very hard to say no to requests, but if it doesn’t align with the vision for the product, the product owner should be saying no, but providing the reasons for it in a friendly, and courteous manner.

Size matters! Small is good (for user stories)

A product owner must be able to

  • take the high-level vision and start to deliver value early on
  • in collaboration with the team, turn the vision into a prioritised list of user stories that are small enough to deliver value to the users immediately.

Having user stories that are large, vague, and take a long time to deliver are of no value to anybody.

Splitting out user stories into small manageable chunks of work also allows you to prioritise and focus on the high-value items that should be worked on first.

Becoming good at breaking down user stories into smaller chunks has the following benefits

  • Helps prioritise the high and low-value user stories, allowing the team to always work on delivering high-value user stories, and not waste time on low-value items
  • Focuses the team on building what’s right for the product and the overarching vision
  • Reduces risk by allowing you to concentrate on completing the hard to do things first. Generally, items that are of high value tend to be hard to do. By focusing on this first, you reduce risk on the project
  • Early feedback – by completing small chunks of work, users will be able to feedback to the team and allow them to adapt and change the backlog accordingly

Available, Engaged & Committed

In an ideal world, the product owner should be available to the team at all times. However, most product owners will have other work to do too, so it may not be possible to be 100% available. They should try to spend as much time as possible with the team, preferably face to face, to work in a collaborative manner. If they aren’t available to respond to questions, or participate in team discussions, it’s likely that the project will struggle, due to the lack of leadership. If they aren’t available to provide feedback and sign off for completed user stories, the team is likely to lose momentum on the project. If they can’t be made available for considerable amounts of time to support the team, consideration should be given to a proxy product owner who has the authority to make decisions.

The product owner should also be actively engaged and committed to the project’s success. The more time they spend with the team and is working with them in a collaborative manner, the better the chances of success on the project. An engaged product owner is a natural leader, as they find themselves leading a team through their decisions and makes it apparent to the team that they are committed to the final product. Great product owners build up a very good rapport with the team, and builds relationships with them to allow the team to focus on delivering the right things at the right time.

Great product owners are able to inspire and motivate teams just by being available to the team and working side by side with them to keep the project aligned to the original vision/goal. One of the best things they can do is to sit with the team as much as possible, so that they are available to the team and allow relationships within the team to be built.

Empathy and humility

Product owners have been given permission by senior management to make the necessary decisions to build the right product. With this comes the product power to lead teams and drive their vision forward. Great product owners lead through empathy and humility, working side by side with the team to make the correct decisions. They show their empathy and humility through their past success, continually making the right decisions, and correcting poor decisions to lead the team forward.

Be Prepared

As any good boy scout will tell you, you should always be prepared. It comes as no surprise that great project owners are always prepared. They alway come prepared to the ceremonial agile meetings, they are prepared and ready to make the necessary decisions.

A team will have greater confidence in their product owner, if they’re prepared for everything. If a product owner isn’t prepared, it will quickly become apparent, and the teams trust will be lost very quickly. It’s essential (and important) that the product owner is always prepared to lead the team, turns up to meetings with the right material, and takes pride in their work.

In God we Trust

No, I’m not trying to convert anybody to become religious, or even pledge their allegiance to the USA (‘In God we trust’ appears on a $20 bill). What is fascinating about religious people is their trust in their faith and trust in God (or gods for that matter). Some may even say it’s blind trust.

So what has trust got to do with being a good product owner? Well, quite a lot actually. Having a product owner that trusts the team to make the right decisions, and vice versa having a team that trusts them is great for team harmony and more importantly being productive. Having a product owner that trusts the team means they can convey their vision, and know that the team will do their best to achieve that goal. From the team’s perspective, having trust in the product owner means they’re doing the right thing and taking the necessary actions to deliver their vision for the product.

Having a team and a product owner that trust each other doesn’t’ just happen overnight. As the saying goes, trust has to be earned. Good product owners will establish a culture of openness and honesty within the team and encourage everybody to always be open and honest with each other, knowing that decisions and actions are being made for the betterment of the vision everybody is working hard to achieve. Trust also leads to respect. Having both trust and respect within the team and with the product owner helps immensely to deliver the right thing, at the right time, and with quality in mind.   



Building Desktop Apps With Electron, Webpack and Redux

by Roman Schejbal

In March 2016, as a part my annual training budget – a perk that every badger gets – I had the opportunity to go all the way to the Fluent Conf, which was in sunny San Francisco. You can read the best bits from the conference in Alex's blog.

One of the workshops I attended was about building a basic desktop application with Electron, that’d be compiled for every major OS and I’d like to share the knowledge and the takeaways I grasped during a 3 hour long session.

We’ll take a high level look at how Electron works, but we’ll also use ES2015/16, Git, Webpack, Babel and a bit of Redux, therefore it’s good to have a clue about what those are so we can focus on our topic and it’s not too overwhelming. We’ll see how we can implement live reloading and get that fast-paced development cycle that most of today’s developers are used to.

What we’ll be building

To highlight some of the things that a desktop application excels in from a normal web app, we’ll need to build something using the native features. Electron provides many APIs above the native functionality and I’ve decided to build a simple HackerNews app or a watcher, that’ll let me know when there is a popular post (>= XXX votes), because I don’t want to miss those and it’s quite reasonable size of a project for this purpose. Well, at least I thought so when I started writing this blog. ¯_(ツ)_/¯ You can download the app (for Mac) here.


If we go to the Electron homepage, we’ll find quick startup instructions at the bottom of that page; so startup your terminal and let’s get on with it!

Note: make sure you have the latest node and npm installed to avoid any potential errors

# Clone the Quick Start repository
$ git clone https://github.com/atom/electron-quick-start

# Go into the repository
$ cd electron-quick-start

# Install the dependencies and run
$ npm install && npm start

After running those commands you should have a Hello World app running on your desktop.

Main Process

What you see is genuinely a browser window, in electron we call them renderers and they are created by the main process. By main process we mean the main script defined inside package.json. You can think of it like a parent of all it’s children (renderers) that is responsible for creating instances of the BrowserWindow class. This is also the place where you’d work with file system operations for example.

Renderer Process

The browser window you see is one renderer process. Electron uses Chromium for displaying pages, but it’s topped with some Node.js APIs allowing interactions on a lower level.

Now that we know the entry point, let’s have a look into it. It’s pretty well commented out of the box so should give you a good idea what’s going on in there.


'use strict';

const electron = require('electron');
// Module to control application life.
const app = electron.app;
// Module to create native browser window.
const BrowserWindow = electron.BrowserWindow;

// Keep a global reference of the window object, if you don't, the window will
// be closed automatically when the JavaScript object is garbage collected.
let mainWindow;

function createWindow () {
  // Create the browser window.
  mainWindow = new BrowserWindow({width: 800, height: 600});

  // and load the index.html of the app.
  mainWindow.loadURL('file://' + __dirname + '/index.html');

  // Open the DevTools.

  // Emitted when the window is closed.
  mainWindow.on('closed', function() {
    // Dereference the window object, usually you would store windows
    // in an array if your app supports multi windows, this is the time
    // when you should delete the corresponding element.
    mainWindow = null;

// This method will be called when Electron has finished
// initialization and is ready to create browser windows.
app.on('ready', createWindow);

// Quit when all windows are closed.
app.on('window-all-closed', function () {
  // On OS X it is common for applications and their menu bar
  // to stay active until the user quits explicitly with Cmd + Q
  if (process.platform !== 'darwin') {

app.on('activate', function () {
  // On OS X it's common to re-create a window in the app when the
  // dock icon is clicked and there are no other windows open.
  if (mainWindow === null) {

On the application ready event we call the createWindow function that’ll instantiate a new BrowserWindow (a renderer process) and load url 'file://' + __dirname + '/index.html;' which is our main html file, from there on we are in our very known single-page application land. Also, we programmatically open the Developer Tools by calling mainWindow.webContents.openDevTools(); since Cmd+Alt+J does not do anything inside Electron.

Looking into the index.html we can see there is a usage of the global process variable and as you know this is not available in a normal browser window. It carries all the environment values that can come in handy as we’ll see in our app.


<!DOCTYPE html>
    <meta charset="UTF-8">
    <title>Hello World!</title>
    <h1>Hello World!</h1>
    We are using node <script>document.write(process.versions.node)</script>,
    Chromium <script>document.write(process.versions.chrome)</script>,
    and Electron <script>document.write(process.versions.electron)</script>.

I mentioned that the renderer is topped with some Node.JS APIs, the process variable is one of them. The other one worth mentioning is that you can actually use require on the client and load modules as you do in Node environment, but we’ll go a slightly different direction today.

The setup

We’ll use Webpack with it’s hot module replacement (HMR for short) for live reloading. So we need to build a little server that’ll host and reload our code while we develop.

In order to do that, we need to install a few node modules:

npm i -—save-dev express webpack webpack-dev-middleware webpack-hot-middleware webpack-target-electron-renderer

Then we create a basic webpack configuration:


var webpack = require('webpack');
var webpackTargetElectronRenderer = require('webpack-target-electron-renderer');

var config = {
  entry: [
  module: {
    loaders: [{
      test: /\.jsx?$/,
      loaders: ['babel-loader'],
      exclude: /node_modules/
    }, {
      test: /\.css$/,
      loader: 'style!css-loader?modules&importLoaders=1&localIdentName=[name]__[local]___[hash:base64:5]!postcss-loader'
    }, {
      test: /\.png|\.svg$/,
      loaders: ['file-loader']
  output: {
    path: __dirname + '/dist',
    publicPath: 'http://localhost:9000/dist/',
    filename: 'bundle.js'
  resolve: {
    extensions: ['', '.js', '.jsx'],
  plugins: [
    new webpack.HotModuleReplacementPlugin(),

config.target = webpackTargetElectronRenderer(config);

module.exports = config;

Since the electron index.html page is running from the file system, we need to provide a correct path for the webpack-hot-middleware so it knows where to connect. Same goes with the output.publicPath for the webpack-dev-middleware so the reload of scripts works properly. The webpack-target-electron-renderer is needed to set all of electron built-in modules as externals plus some other bits here and there. You can find out what exactly it’s doing in the npm package itself.
Also, as you can see we’ll use babel and css-modules so we actually need to install a few more modules which you can do with this command:

npm i —-save-dev babel-cli babel-loader babel-polyfill babel-preset-es2015 babel-preset-stage-0 babel-preset-react css-loader style-loader postcss-loader

Now that we have our config, let’s write up the server and connect it to Webpack.


import express from 'express';
import webpack from 'webpack';
import webpackDevMiddleware from 'webpack-dev-middleware';
import webpackHotMiddleware from 'webpack-hot-middleware';

import config from './webpack.config.development';

const compiler = webpack(config);
const app = express();

app.use(webpackDevMiddleware(compiler, {
  publicPath: config.output.publicPath,
  stats: {
    colors: true



Update the index.html to use the built javascript.


    <div id="root">
      We are using node <script>document.write(process.versions.node)</script>,
      Chromium <script>document.write(process.versions.chrome)</script>,
      and Electron <script>document.write(process.versions.electron)</script>.
      (function() {
        const script = document.createElement('script');
        script.src = process.env.ENV === 'development' ? 'http://localhost:9000/dist/bundle.js' : './dist/bundle.js';

Then tweak the package.json for a babel configuration and a startup script:


  "main": "index.js",
  "scripts": {
    "start": "ENV=development electron .",
    "server": "babel-node server.js"
  "babel": {
    "presets": [

But now we have to run two scripts to startup the app.

npm start
npm run server

Let’s get rid of that by installing the concurrently module npm i —-save-dev concurrently, update the package.json once more and we are back to one command:
npm run dev


  "scripts": {
    "start": "ENV=development electron .",
    "dev": "concurrently -k 'babel-node server.js' 'npm start'"

Engage dev

Until this point, we were setting up the development environment to have this convenient developer experience. From here we’ll actually start building our app, but I want to apologize for omitting (on purpose) quite a lot of app-specific stuff just because we want to primarily focus on the electron APIs and see the usage of it. In any case, you can find the full source code on my github.

Inside the webpack config we’ve set the entry point to ./src/index, so here is the content of it.


import 'babel-polyfill'; // generators
import React from 'react';
import { render as renderReact } from 'react-dom';
import debounce from 'debounce';
import configureStore from './store/configureStore';

const state = JSON.parse(localStorage.getItem('state'));
const store = configureStore(state || {});

let App = require('./components/app').default;
const render = (Component) => {
  renderReact(<Component {...store} />, document.getElementById('root'));

if (module.hot) {
  module.hot.accept('./components/app', function() {
    let newApp = require('./components/app').default;

const saveState = debounce(() => {
  localStorage.setItem('state', JSON.stringify(store.getState()));
}, 1000);
store.subscribe(() => {
  if (process.env.ENV === 'development') {
    console.log('state', store.getState());
store.dispatch({ type: 'APP_INIT', store });

Since we are using Redux and having a global state of the app on one place, we can use this minimal HMR mechanism that’s inspired by Dan Abramov’s blog.
Basically we re-render the app every time when something that’s imported under the App or even the App component itself changes. If it’s something else, we then refresh the whole page as this is set by query parameter reload=true inside our webpack config. Additionally we could write a reducer replacement mechanism so the webpack doesn’t have to refresh the page when we update actions, reducers or sagas. On any change of the state we save it into the localStorage, therefore we don’t really care about losing the state after refresh.

Moving on


function fetchTopStoriesApi() {
  return fetch(`https://hacker-news.firebaseio.com/v0/topstories.json?print=pretty`)
          .then(response => response.json())
          .then(stories => stories.map(storyId => ({ id: storyId, loaded: false, loading: false })));

I’m using redux-saga but feel free to use anything else like redux-thunk or not redux at all! The key thing to see here is the native fetch function for collecting HackerNews stories. I want to point out that in a normal web application I wouldn’t be able to do this (at least on the client side) because of CORS. But since we are in a native-like application, there’s no restriction on CORS in Electron.

Once we have the stories inside our state, we can print them out and attach some onClick handlers. In a normal web application we’d just create the anchor tag and give it a href, but if we do this inside an electron application and then click on the link, electron would load the page inside giving us no option to go back! What we want instead is to open the story in the user’s default web broswer. That’s where the electron’s shell module comes into play.


import electron from 'eletron';
handleClick(story) {
    return (e) => {

Now let’s just skip all the other components, reducers and have a look at one particular action.


export function notifyAboutStory(story, onClick) {
  const notification = new Notification(`Hacker News ${story.score} 👍💥 votes`, {
    body: story.title
  notification.onclick = onClick;

This is where we trigger the native notification to pop up. It follows the Web\Notification API so if you, for example, want to make it silent, you’d just add that as an option inside the options parameter within the constructor.

Communication between processes

Sometimes, depending on what we’re building we might need to communicate from the renderer process to the main process. It could be anything from a native open-file dialog that’s available only on the main process, or simply quitting the application with app.quit() as we have here.

Processes may communicate by messaging each other via ipcRenderer or ipcMain (depending on what side is being implemented) which is basically an instance of EventEmitter and we use it like this:

Event emitting:

import electron, { ipcRenderer } from 'eletron';
<button className={styles.quitBtn} onClick={() => ipcRenderer.send('quit')}>Quit App</button>

Listening on event and taking an action:

var ipcMain = electron.ipcMain;
ipcMain.on('quit', () => {

Driving this home

From the screenshot above you can see we have the app inside the OSX menubar, we’ll use this menubar package for it’s ease of use and all we have to do is to update our main.js to implement it.


var menubar = require('menubar');
const mb = menubar({
  'width': 500,
  'height': 700,
  'preload-window': true,
  'resizable': false
mb.on('ready', function ready () {
  console.log('app is ready')
  // your app code here

Building the app

For building the app we have a special webpack production config, that just overrides some of the development configuration and saves the build into a dist folder.

Then we use electron-packager to get the actual executable build.

Our final scripts section inside package.json looks like this:


  "scripts": {
    "start": "ENV=development electron .",
    "dev": "concurrently -k 'babel-node server.js' 'npm start'",
    "build": "webpack --config webpack.config.production.js && electron-packager . HackerNews --platform=darwin --arch=all --overwrite"

And that’s it! If you have any questions, use the comments below or get in touch on twitter.


London React Meetup – March 2016

by Joe Paice

This month we were back at the London Facebook office for another brilliant London React Meetup. We had another full house with plenty of pizza, beer and React geekery.



For this meetup we had two presentations. Red Badger’s very own Stuart Harris gave a talk on Redux Sagas and Facebook’s Martin Konicek gave us a look under the hood of React Native.

Managing and testing side-effects in Redux with Redux Saga

Stuart Harris – Red Badger



Stu gave some great insight into how to go about incorporating Redux Saga into Redux applications. Redux Saga is a Redux middleware that handles asynchronous actions in your applications. Instead of dispatching Thunks which get handled by the redux-thunk middleware, you create Sagas to gather all your side effect logic in a central place.

Stu took us through what Sagas are, how to use them and how easy they are to test. No more crazy spies or mocks. No more manipulating time or rewiring dependencies. Just pass in actions and test the output effects.

If you are having trouble with asynchronous actions in your project perhaps Redux Saga can help.

Under the hood of React Native

Martin Konicek – Facebook


Martin works on the React Native team at Facebook. He gave a great tour of React Native with a focus on Android development.

Martin delved into the porting of Facebook’s Ads Manager app from iOS to Android. He demonstrated some of the ways they were able to share code across both platforms, boasting over 85% code reuse in the Ads Manager.

Martin elaborated on the architecture and extensibility of React Native and gives some insight into the React Native Open Source process. It is pretty amazing how Facebook handles syncing their internal React Native and the public React Native on GitHub. I look forward to more tools like the Facebook Github Bot to help developers manage their open source projects.

The recordings of the talks will be available shortly, we’ll post a link here soon.  Thanks to Stu and Martin for their great talks, Facebook for hosting and the members of the community that joined us! Join the meetup group to receive updates on future events!


Badger Digest – April 2016

by Alex Savin

Image by Chris Beckett, used with Creative Commons license

Fresh issue of Badger Digest bringing you the most discussed topics and links from our 100+ private Slack channels over the past month.




One line news

  • Amazon EC2 Container Registry (ECR) is now available in the EU (Ireland) region