Category Archives: Building a business

How to turn a Podcast RSS feed into a website

As I wrote previously, getting started with a Podcast can be very straight forward. Todd and I wanted to add some personality to our show’s online presence, so we decided we needed a website. A lot of the information that would normally go on the website is already available in the Podcast’s RSS feed, so I started thinking about a way of not duplicating this effort. The Keep In Touch show is a hobby, and given how busy (and lazy) I am at the moment, I needed a pragmatic solution.

TL;DR

KeepInTouch.fm runs on Jekyll and is updated every time we publish an episode using our fork of the Jekyll RSS importer. We upload the episode and its metadata to our Podcast host and then we point the importer at the Podcast RSS feed. If needed, we customise the blog post and then push it to GitHub. GitHub pages then automatically updates the website.

List of requirements

We wanted the website to provide some fairly basic functionality:
– general information about the show, and a the ability to subscribe to the Podcast
– a blog/website where each episode can have its own page
– each episode page would need to privide visitors with the ability to listen to the show, and to find shownotes, links, and other relevant information

As the administrators of the website, we would need:
– a modern website: responsive, fast, and secure
– an easy to maintain set up (i.e. no hardware / software maintenance)
– a simple updating mechanism
– a simple way of transforming the information we had already provided in the Podcast’s RSS feed

The solution

GitHub Pages was the first option we considered, and luckily it ticked all our boxes. We quickly set up an organisation and picked a simple, but quite configurable jekyll theme for the site.

The only friction I still had to deal with was the “transformation” of the Podcast RSS feed into blog posts on the site. Jekyll does come with an RSS importer, so I gave that a go. Most of the metadata was extracted nicely, but there was no way to play the show without changing the post manually to link to the mp3 file that was actually available in the RSS feed.

Open Source FTW

Luckily, the Jekyll project is open source, which meant I was able to fork the RSS importer, and turn the RSS audio enclosure into an HTML audio tag. All it took was 13 lines of code.

The result

Today, my workflow couldn’t be (?) simpler:
– Record and edit the show
– Upload the episode and it’s metadata (i.e. shownotes) to the podcast host
– Run a simple script to fetch the new episode (and turn it from a feed Item into a blog Post)
– Push the new post to GitHub

If you found this post useful, please consider subscribing to KeepInTouch on Apple Podcasts, Google Podcasts, or wherever else you listen to podcasts. If you like what you hear, please leave a review. Lastly, please send us your feebdack via email or twitter @KeepInTouchFM.

Improved – Get everything done

Over the past two years I have been working alongside my friend (and co-founder) Stef on Improved. Yesterday evening we released the first version to our friends and family.

I won’t go into what Improved is because its website covers all that; this post exists so that I can mark the moment when this all happened. Suffice to say, our vision is to

Remove the guesswork from finding the right person for the job

Some background info

People who know me closely are aware of the fact that I am a big fan of the Lean Startup model. Yet I just said that we’ve been working on this project for a couple of years, thus contradicting my previous statement.

Here’s my excuse: I have a day job, as Head of Mobile at Trade Me, and this job takes up at least 4 days of my week (sometimes I take work home with me). On Tuesdays however I get to work on what I am passionate about. For the past couple of years I have been spending my Tuesdays juggling work on Improved, with some other client work (for my boutique consultancy called Tmro), and with some other family activities.

This dynamic has kept my brain engaged at 100% and has produced an incredible amount of work related satisfaction (be it Improved, Tmro, or Trade Me). Without a doubt, all these companies / products have benefited from the experience I accumulated while working on the other ones.

Improved is the most recent initiative of this bunch, therefore it took a lot longer for the fruit of the work done on it to show. That ends today.

All in all (an including evenings and weekends) I’ve spent between 4 and 6 work-months building Improved. I am not counting here the effort and work poured into the project by Stef, who’s been doing a bloody awesome job in a similar 1 day a week arrangement for a period almost as long.

Stocktake

We decided to ship our MVP at the point where the platform supports the use cases we considered to be necessary (after doing plenty of soul searching and chatting to other people).

Roughly, these are the “features” of our v1:

The simplest possible create and manage Job flow
Support two way messaging and quoting (including Push Notifications) between job owners and service providers (aka Improvers)
Search and browse Jobs and Portfolios
“Smarts” that support our vision:
- photo doodling
- take similar photo assistant
- before and after comparison tool
Social login and straightforward account creation
Seamless Native app to Web handover
Clear feedback/review process

Could we have done more? Absolutely! Our backlog is chocka full. Should we have done more? We think not. We want (and need) feedback from our users so that we shape the product into something that people love using.

After the first few user interviews we realised just how differently people think of their interactions around a job. Waiting longer and shipping a more “feature rich” product would basically mean increasing the number of assumptions made. This is a risk we chose not to take.

The next steps

Yesterday we started inviting Beta testers to use the app. We hope that everyone who uses the app (whether they have jobs they want done or they just look for their next customer) will find it useful.

We have an Android app underway, as well. I will shift my attention to finishing that app, while supporting the “early adopters” with anything they may need.

I’d love your help

If you’re reading this, chances are we know each other. Hi! You can help too! Get in touch with us by email and we will add you to our Beta test group. Improved is free for everyone to use, and posting jobs is non commital until you accept a quote (just like in real life).

Here are some other ways you can help:

you can upload DIY projects you have already done. This way we can learn more about the types of jobs people do, and the language they use to describe them
next time you need to mow the lawn, or prune a tree, or take classes or lessons of any sort, post a job on Improved. It’s free and you can build a pretty neat portfolio that you can be proud of
visit our website and send us any feedback you can. Is is clear what the product does? Do you like / dislike anything? Do you have any recommendations
spread the word. We have a Facebook Page, a Twitter account, and a Website. Please send our way all the to people you know who need stuff done around the house, who used a dog walker in the past, who took lessons or classes of any sort. Our mission is to enable people to be the best they can be at what they do.

Thank you.

Link

The Design of Business: Why Design Thinking is the Next Competitive Advantage.

The Design of Business

I just read this book, and it was good. Not quite 5-stars good, but a good book nonetheless. A couple of chapters definitely stand out. The P&G analysis is fantastic, while the RIM introspection is hilarious. To be fair, it’s only funny because RIM stopped doing what the book is praising them for.

Here are a some of the notes I took (hopefully I don’t break copyright):

The minute you start analyzing and using consumer research, you drive all the creativity out of the product.

No good product was ever created from quantitative market research. Great products spring from the heart and soul of a great designer, unencumbered by committees, processes, or analyses.

Even as corporate leaders chase the vital, elusive spark of creativity, their organizations structures, processes, and norms extinguish it wherever it flares up.

Once knowledge has been pushed to a logical, arithmetic, or computational procedure, it can be reduced to software.

In most large business organizations, three forces converge to enshrine reliability and marginalize validity: the demand that an idea be proved before it is implemented, an aversion to bias, and the constraints of time.

An organization that engages exclusively in exploitation will ordinarily suffer from obsolescence.

Of the original Fortune 100 companies, published in 1955, only eleven are still on the list.

When a team can come together around a creative cause or a knotty problem, they want to come to work every day.

Laliberté (founder of Cirque du Soleil) had done no research to forecast the size of the market for his new form of circus. How could he? The market did not yet exist.

and finally, one of my favourites:

Mastery without originality becomes a cul-de-sac.

Next on my list: Business Adventures: Twelve Classic Tales from the World of Wall Street

Team vs Group – Some differences

A bunch of people that push each other forward and work together for a common goal form a team. A number of people who work for the same organisation but have individual goals belong to a group. One of the biggest differences between a team and a group is that a team’s achievements always outweighs the sum of all the individuals’ accomplishments.

To better explain my point of view, I will break down my definition of a successful team into the categories below and close with what I believe the manager’s role should be.

Motivation: Purpose, Accountability, and Goals

People in a group are very likely to be sold a goal. Depending on their professionalism, they will push themselves to achieve great outcomes and they will strive to be honest. Any failures or imperfections are forgettable and are perceived to be short-term. Accountability applies at personal level. In this context, the motivation for an individual is most often extrinsic.

In a team, the goals are set together through discussions, planning, and by sharing a common definition of success. The team has personality. Since the goal is shared, they push each other forward and hold each other accountable. Due to the fact that they collaborate closely they often end up raising the bar of expectations for each other in order to deliver better results at both personal and team level. Team players are intrinsically motivated.

Collaboration and Roles

In a group, individuals are less likely to contribute to other skills

In a work group, people share information, they are respectful with one another, and sometimes even behave in a formal way. Meetings sometimes turn into status reporting. Peoples’ ideas don’t always get challenged or augmented. There’s hardly ever any work done outside one’s area of expertise. The skills overlap is kept to a minimum, almost as a sign of respect. Personal development is determined by one’s own desire to better themselves rather than as a need to fill a gap. A designer is always a designer and a tester is always a tester. The Gantt¹ chart for how a project runs is clear-cut. Task B always follows task A and never comes after task C.

In a team, individuals tend to push their peers forward

In a team, the collaboration is not just close, but from the outside it may even look chaotic. There is energy and people often venture beyond the limit of their skill. Developers and testers may end up sketching design approaches. Designers may roll up their sleeves and help with testing. Product owners will join the designers in user testing. Personal development is often done in a way that completes the collective knowledge. A tester may learn to use prototyping tools, while a designer may learn how to work with development tools. Each person may wear the hat of any of the other team mates and may jump in when their help is required. In a Team, tasks A,B, and C may take place at the same time and make a project manager’s life a living hell.

The Manager’s role

In a work group, the manager is almost a dictator (sets the goals, measures progress, and is the only one who can push a member’s limits). In a team, the manager is merely a guide and a facilitator.

All teams start off as a group. It’s a manager’s job to create an environment where people:

feel safe
speak freely
are comfortable with themselves and can be genuine

so that they can discover each other’s strengths, accept the weaknesses, and, over time, build trust.

¹ Disclosure: I really don’t believe in Gantt charts.

Log In – A recipe

In a previous post I was talking about the log out experience, and the contents and functionality that I think should be included on the Logged Out page. Today I will tackle the Log In page (if you really must have one).

If you must enforce the use of an account then this should happen as painlessly as possible. Both you and the user are probably in agreement that this step is required only because we haven’t yet come up with a simpler way to establish this trust relationship. Further down, you can find a few suggestions on what may become, one day, a more seamless authentication pattern.

The authentication & authorisation topic is large. In a nutshell, identity verification takes into account three factors:

Something you know (username, password, secret question, etc)
Something you have (physical token, card, dongle, phone, etc)
Something you are (fingerprint, retina scan, voice recognition, etc)

In this post I will only discuss the first point above. Even when I include items from points 2 and 3, I will do so with the intention of making point 1 simpler, rather than to increase the security of the authentication mechanism. In this post I’d like to stick to making things easier, rather than more secure.

Ingredients

The Log In page must have a few basic ingredients:

Credentials form. The focus should already be given to the first field (i.e. user id). Avoid captchas at all costs.
Password recovery link. Usually the “Forgot your password” prompt will also follow a predefined number of failed log in attempts. Care must be taken around “leaking” valid email addresses.
Sign Up option.

On top of the the above items, there are a few more ingredients that can help make the log in experience more painless:

Language switcher. If you’re site is localised, then this is a must have. Always include the current UI language in the list of available languages (so that the user always knows that they can switch back to it).
Password privacy toggle. Some passwords can be quite complex. If the user is in the privacy of their own home they may prefer to see what they’re typing.
Remember me. I’m not a huge fan of this option. I feel like this toggle is better placed in a global settings area of your site.

Recipe

Twitter’s Log In page is minimalistic

Mix all the must have ingredients above, add your preferred nice to have items and you should get a pretty decent log in form. Rather than me drawing up a log in form, I chose to complete the picture and include the log in forms for the sites I mentioned in the Log Out post.

Facebook is not confused; it’s on a mission

Notice how Facebook almost gives more priority to the Sign Up process. That is probably tied into their drive to get more users onto the platform (warning: pure speculation). The other very interesting thing about Facebook’s Log In page is just how similar it is to their Logged Out page. Can you spot the difference?

For some inspiration, have a look at this set of Mobile Log In pages.

One day

Here are a few suggestions on how authentication could, one day, be simpler.

Trust my location

If I Log In from the a certain location (IP / WiFi / etc), there are no other people using the site, I always use the same browser, etc then maybe you can “assume” it’s me. Maybe you can prompt me to allow you to make that assumption?

Delegate the identity check

To my phone. If my mobile device has just started using the same public IP, or is in the proximity of the device that I am trying to Log In from, you can probably “assume” it’s me. If you want to be sure, maybe you can build support for Handoff / Continuity in your site and trust my mobile device to do the authentication.

Voice sign in

What if there was an app on my computer that I could start and I could say: “log me in to Facebook”? This app could check my voice, unlock my keychain, extract the credentials, start a browser/tab and fill in the form for me.

Log Out – Please take me with you

Your user has logged out (Signed Off, Logged Off, Signed Out, etc). What happens next?

Many online experiences end there. I believe that to be a missed opportunity. The page that gets displayed to the user as a result of logging out is an integral part of the online experience that your site provides.

Why has the user logged out?
A few reasons spring to mind:
1. they want to switch accounts
2. they’ve been inactive for too long and the system logged them out
3. they have finished using the site and they use a shared computer

These are just three possible reasons, but they are probably enough to draw some quick conclusions about what a good log out page may contain.

What should the logged out page be?
Regardless of the reason why the log out took place, the user should be shown a confirmation message. They need to know that their wish was granted, or that they have been logged out for some other reasons (such as their inactivity).

Facebook invites the user to “stay connected”

Twitter asks the user to get the apps

Reasons 1 and 2 above virtually require that a log in form be present on the page.

Reasons 2 and 3 can be regarded as an opportunity for reaching out to the user with an invitation to continue their interaction with your site through a more personal channel, a channel that is secure and omnipresent: the user’s mobile device!

Why not remind the user about your mobile app, or your mobile website. Tell them to take you with them by installing your app. Better still: make the most of features such as Continuity to allow the user to continue their session on their mobile device.

The rest of the content that should go on this logged out page is not so obvious. It’s not just a matter of taste, it’s also a matter of personality. You can consider the user disengaged and show them an ad. Or you may take this opportunity to strengthen your brand. You may even go all melodramatic and put a “sorry to see you go; please come back soon” message.

Whatever you decide to do, just try and think of this page as an integral part of your product. Don’t think of it as the end of the line and you may end up building an avenue for increasing engagement and retention.

Apps vs. Websites – The ownership perspective

This topic has been covered time and time again. Typically, these articles cover a mix of technology, performance, ROI, look and feel, and other such metrics.

Today I’m going to suggest that the end user’s ownership of an app (as opposed to a website) is one criteria that businesses should consider when making the decision to build a Native App. I’m also proposing that building a Responsive Website is no longer an option, but an expectation.

In 2014, even the cheapest smartphones come with HTML5 capable browsers! End users do not and should not have to understand why a website is different, and sometimes even feels alien, when viewed on a mobile device. The time when we had to compromise on mobile because of technical reasons is long gone. Let’s leave this here.

If the mobile browsing experience is in the same class as the browser experience then why should you even consider an app?

Unless you’re planning to build an amazing app that you plan to support long term, keep up to date with the fast evolving mobile UI/UX, in which you utilise the mobile platform paradigms to the point that the user feels like it was built in collaboration with the designers of the first party apps, then you probably shouldn’t build an app.

The subtlety here is that it all boils down to the fact that you own your website, but the end user owns your app.

If the user has a bad experience on your site, they can’t get rid of your mobile optimised (hopefully responsive) website. Your links will always work, even if they remove all shortcuts or bookmarks. A short url, a web search result or an ad will always be able to bring them back. When they’re back you’ll have a chance to make them change their mind and convince them to return in the future.

On the other hand, if the user has a bad experience with your app, they can simply forget the app ever existed on their device. They will delete it and they’ll do that almost as a punishment for your failure to delight them. Deleting the app will close all the communication channels once provided by that medium: all extensions and widgets will be gone, all URL schemes will seize to function. The reality is your app is competing with potential photos of their friends and family, or with another app that is more in fashion than yours.

The end user owns your app because they install it, they dedicate disk space to it, and they can get rid of it if they choose to. They are in complete control of this lifecycle and, you may not realise this, this lifecycle has financial and psychological implications.

Unlike accessing your website, when installing your app the user is likely to be asked for their password (or fingerprint for Touch ID). Even if your app is free, the psychological connection is made: they acquired your app. They are now using disk space just to have your app around.

Your app must be delightful, it must add value every time it’s used, otherwise the user will eventually run out of patience and delete it. Once they do, you will face a big uphill battle to convince them to give your app another try.

There is no such psychological attachment to your website because the user is not involved in the site’s lifecycle. They usually just “ask” a search engine for it. When they run out of space for their next photo they won’t think which sites they can remove…

If you can’t build a delightful mobile app, then you’d better have an amazing responsive website. The reality is though, that if you don’t have both, then it’s likely that you’ll never be the first port of call for a mobile user.

Defining a product roadmap – The pyramid of trust

The Product Roadmap is like the north star. The same way a sail boat is guided by a trustworthy, never changing light source, the Product Roadmap is there to give a team direction and comfort that they are moving in the right direction.

The goal

The goal is to get the team to be intrinsically motivated about the Product Roadmap. I’m making the assumption that if you’re reading this post you probably agree that selling a roadmap to the development team is a difficult undertaking.

In order to be able to provide direction and comfort, the Roadmap has to have the team’s buy in. In the remainder of this post I will describe the way I believe a team should be approaching the definition of a successful Roadmap.

The actors

The teams are made of a number of skills. Some teams can have just two tiers (or just one when the leadership is provided from whithin the team) while in larger organisations there can even be a structure such as the one below.

Product Manager	Ultimately responsible with the delivery of the product
Technical Lead	The technical go to person for the entire team (cross skill)
Team Leader	Responsible with the entirety of a skill (e.g. developers)
Team Member	BA, Designer, Developer, Tester, etc

In reality, the more tiers there are in a team the higher the risk that there will be voices that have not been heard or that certain individuals will end up not feeling represented. Later in the life of the product these are most likely to become the least motivated or the least engaged team members.

The approach

I believe that people’s motivation disappears when the Roadmap is enforced top down. Too much energy has to be spent on selling a roadmap epic as opposed to discussion the merit of that roadmap entry.

Instead, I suggest a bottom-up approach. I call this, the Pyramid of Trust. I will describe how this works by looking at a complex team structure. In a simpler situation, pyramid levels could simply be removed.

The Pyramid of Trust … is built from the ground up

Step 1 – Ask the team

Everyone takes part in this exercise. Allocate enough time to allow people to collect ideas and to have a couple of minutes to pitch them. There are no bad ideas at this point. Think of it almost as a brainstorming phase.

This first step is also the most important one, because this is where trust starts being built. Here are some guidelines on how to approach it:

Remind the team about the company values / mission / priorities
Ask them to suggest a limited number of ideas (no more than 3). These ideas must be good for the product, for the end user, and for the business
Once the team have spoken, it’s time for their leaders to contribute with their own proposals
Lastly, the Product Manager / Business Owner is going to present their own idea

Step 2 – Find the themes

Realistically there will be many ideas that the team simply won’t have time to build. Some ideas might just be plain bad. Other ideas might need resources that simply are not available. These are just a few reasons why in step two, the Team Leaders should get together with the Technical Lead and the Product Manager to:

group these ideas by theme
discard themes / ideas that are not suitable

Delegating or sharing this responsibility with the Team Leaders is beneficial because:

it gives comfort to the team members who know that they are represented in the selection process
teaches the Team Leaders about responsibility and pragmatism
is a healthy process that enables excellent technical proposals to survive the selection process

Step 3 – Isolate the Epics

It’s time for the Technical Lead and the Product Manager to make the final selection for the Epics that will make it into the Roadmap.

This is the step where emotion is put aside and the business and the technical skills get together to figure out the best ways forward. At the end of this step the Product Manager will have mandate from the development team to pitch a Roadmap to the business.

The Technical Lead will need to figure out ways to plug the holes in the team’s skills set, resource and prioritise appropriately, find training and upscaling opportunities. All these will help the team be as prepared as they can be when they come about implementing this Roadmap.

Step 4 – Pitch the finalised Roadmap

The Product Manager is now under pressure from the team to represent their ideas when pitching this Roadmap to the wider business or to the stakeholders. Compromises usually need to be made and not everything will work according to “plan”. The bright side to this approach though is that the Product Manager will have the confidence to speak on behalf of the team knowing that if their suggestions make it into the agreed Roadmap then the team are likely to be motivated and engaged as they are, in fact, co-owners of this Roadmap.

Conclusion and next steps

It’s important to remember that if an idea that was generated by a team member makes it into the final roadmap, this person should be involved in the phases to follow: exploration, research, strategy, implementation. This way credit is given where it’s due, the sense of ownership and belonging is reinforced and this becomes a good example for the roadmap sessions that will take place in the future…

A good idea would be to make the roadmap as visible as possible, in a way that does not use actual dates. The focus should be on sequence more than anything. I would suggest three monthly updates on progress. These would also serve as reminders of the common team purpose.

Nick Parfene

Technology. Community