5 min read
At Known, we recently kicked off our latest sprint by facilitating a prospective review. Rather than wait until a project has failed, this design thinking-flavored activity was intended to give the team an opportunity to consider what might prevent us from finding sprint success and reaching our intended goals.
The prospective review was something that we led for a handful of companies working out of Matter Ventures. Every company is in a different place with their business and product, but each is following a loose cycle of 6-week sprints. Each has an overall goal that they're working toward during the period, and at the end of the sprint the companies present their progress in a design review, in front of an audience of peers.
Product sprints work in part because they allow teams to flexibly evolve a product within the constraints of a certain timeframe and scope. By starting our next 6-week sprint with a prospective review, company team members have the opportunity to come together and share thinking around the risks, challenges, and problems that might arise and prevent them from reaching their target. Where most learnings and takeaways for failed (and successful) projects happen at the conclusion, the prospective gives everyone an opportunity to look into the future, brainstorm possible outcomes, and discuss plans for preventing anything negative.
The prospective review also gives everyone a space to share their concerns and worries ahead of time, before they build up during the course of the sprint. The goal is to get everyone on the same page early on, thinking about the intended goal and preventing negative outcomes before they happen.
We rely on whiteboards, sticky notes, and timers for group exercises like these. Before the brainstorming starts, each team member should have a sticky note pad and a pen. The whiteboard can be divided into three sections for the exercise: a cell on the left for bad assumptions, a cell on the right for action plans, and a space along the bottom to prioritize assumptions.
The overall sprint goal should be present and fresh in everyone's mind. You may want to leave space at the top of the whiteboard to write it out. Or you could stick the sprint goal on an adjoining whiteboard.
Most of our teams had 2 - 5 people participating.
The first step in the prospective involves listing out all of the things that might possibly go wrong and prevent the team from reaching the sprint goal. Ask your group, "What might go wrong?", "How might this end poorly?", or "What might prevent us from reaching our goal?". Then give the team the opportunity to brainstorm and list out anything they come up with. This is where sticky notes become handy. As a teammate comes up with a bad assumption, they should share it with the group, write it on a note, and place it on the whiteboard.
Bad assumptions (assumptions about what might go wrong or prevent the team from reaching the goal) can be internal and external. Considering some of these less desirable outcomes can be a bit of a downer, but you'll resolve that during the third step. Sharing these negative possibilities early on helps everyone work together toward the objective - successfully achieving the goal of the product sprint.
Activity time: 10 minutes
The second step of the prospective review is to prioritize your assumptions on the whiteboard. As a team, you'll want to discuss each thing listed and categorize it is high, medium, or low priority. Use the space at the bottom of the whiteboard to move sticky notes from the Bad Assumptions cell to a category under Priorities.
Discuss each concern briefly and make a quick decision based on its importance and likelihood of happening. Try not to get too tangled up as a team debating the priority of any one assumption. The end goal is to have a category of possible bad outcomes that are absolutely crucial to address and prevent.
Activity time: 5 minutes
In the final step of the prospective review, you'll need to write out a quick action plan for preventing or dealing with your most pressing assumptions. During this stage, move each sticky note from the "high priority" class to the Action Plan cell on the whiteboard. As a team, discuss what can be done to prevent this possible bad outcome. Come up with a quick action plan, and write that down next to the sticky note.
Bonus: If you want to expand upon this step further, before you write out the action plans you can order the sticky notes in the Action Plan cell. Depending on the nature of your sprint and the bad assumptions it might make sense to order them "most important to least important", or you might aim for "most likely to happen first to likely to happen last".
At the end of this step, everyone on the team should feel confident that the possible negative outcomes with the highest priority have been addressed with an action plan for prevention or recovery.
Activity time: 10 minutes
Because we completed this exercise as a larger group, with multiple company teams going through the process all at once, we ended our session with 5 minutes for each team to reflect. People shared some of their most pressing bad assumptions and the strategies they were considering to prevent these during the new sprint.
For us, it was an opportunity to talk frankly as a team about some of the things that might prevent us from reaching our sprint goal in the next six weeks.
This exercise was inspired by the Gamestorming "Premortem" activity.
1 min read
We just released Known 0.9.1 for self-hosted users.
This fixes a number of issues, and improves compatibility for users importing RSS feeds. It also introduces notifications: an alpha feature that allows you to see when other people have commented on and reacted to your content (including over webmentions).
We recommend that all self-hosters upgrade. You can download Known 0.9.1 from our open source page.
5 min read
Bots are taking over the web.
You interact with bots just like you would talk to your friends. Ask them a question, and they'll reply. Give them a command, and they'll go off and do it.
All without having to install a new app. Sometimes you don't even have to create a new account.
Natural to use
This was also the promise of web applications: you could run any application you wanted for any purpose, without installing anything other than a web browser. Web apps took off because workers could use software without having to go through their IT departments. Even if your IT department wasn't an obstacle, there was no need to have a specific operating system. Software just worked, across all your devices, with no technical obstacles.
Bots have all of these properties, too - and they have a consistent interface. Whether you have four chatbots installed or forty, you never have to learn a new set of menus or get your head around a new way of working. You just chat.
In a seminal piece last month, Chris Messina (inventor of the hashtag and open web pioneer) wrote about what he called the rise of conversational commerce:
No longer do you need to convince users to “download and install” an app — they can just invite a bot to a conversation and interact with it [eventually] like they would a person. Zero barriers to adoption, with minimal risk to the user.
(Mobile apps, by the way, are turning into a losing game: most users drop off in the first three days, and the vast majority of smartphone users never download any new apps.)
Bots at work
Messaging and notifications. Software automation. Always-on connected devices. Machine intelligence. These elements can be combined to form a very interesting new type of application: the digital coworker — a piece of software that works along side you at your job and participates in the day to day activities of your company as an active and engaged member of the team.
Howdy allows you to ask questions to your team and turns them into a report to help you to make faster decisions. We use it at Known to power standup meetings, but it could also be used to take lunch orders or ask custom questions.
XOXCO raised $1.5m for Howdy, and hired the novelist Neal Pollack to give their bot a unique voice. For me, this is perhaps the most interesting aspect of bot design, and the bit I'm most excited to play with: character development. If you're building a virtual colleague, it had better be an interesting one.
Bots in the media
While announcing his resignation, Owen Thomas, formerly the editor of ReadWrite, noted that:
There’s an amazing opportunity ahead of us to redefine how newsrooms work, driven by data, assisted by artificially intelligent bots, and delivering narrative experiences through new mediums such as messaging apps.
Indeed, Ditherati, his content site, is "an experiment in short-form content delivered via messaging bots". Imagine having a friend who sends you interesting news stories from time to time.
I am interested in the potential of telling a story conversationally. Stories are how we interpret the world, and every relationship we have has a narrative. Again, the ability for writers and artists to craft a human story is suddenly much more important in a bot-led application universe.
More pragmatically, there's also huge potential for bots to be useful colleagues in working newsrooms.
Newsrooms are busy, hectic places, constantly working under tight deadlines. Fast answers are vital. What if you could ask a bot:
What if we could ask it to let us know when [journalist] files their story? What if we didn't have to ask it?
Suddenly every human in the newsroom is freed up to do specialist work, knowing that air traffic control is taken care of.
A universe of bots
It's obvious that there are a million different use cases for this kind of supportive conversational computing. There are lots of repetitive, important tasks we do every day. In a startup, we're constantly checking what we call KPIs: Key Performance Indicators like monthly active users and revenue growth. Being able to ask a bot to track those for us saves us time, and holds us accountable.
Lots of different kinds of applications are possible. There's a universe of different contexts to support, data providers to integrate with, and services to provide.
In all of these situations, you're always having a conversation with information. For the first time, the bot paradigm makes this explicit.
What does this have to do with Known?
So far, most bots have been fairly closed: one bot per application, with very little ability to customize. Meanwhile, every organization has a different context, and a different set of data that they need to have a conversation with.
One of the key benefits of a chat interface is that no matter which bot you're talking to, the output will always be in more or less the same format. A stock ticker bot will tell you a number; so will a comparison shopping bot, a business intelligence bot, a Wolfram Alpha bot, and so on. Suddenly the data from every application on the web can be combined as easily as talking to a friend. We think this will be particularly useful for small teams of people who need quick answers.
It turns out there are lots of ways we can help you have a digital colleague that is yours.
We've been thinking about bots a lot, and we're building something new, that is very different to anything else out there. And we can't wait to share it with you.
You should follow Known on Twitter: @withknown.
2 min read
We're delighted to announce the release of Known 0.9.
This version contains a huge number of enhancements, new features and fixes. It's much faster; it supports non-Latin characters in post URLs and hashtags; it supports Twitter cards; autosave works better and posting is more reliable; search is better; and much more. A lot of this is due to contributions from Kyle Mahan and Marcus Povey, as well as lots of energetic activity across the open source community. You can download it here.
Every version of Known is named to highlight someone whose creative work has influenced our lives. Previous versions have been named for Katherine Dunham, Miriam Makeba and Giotto Di Bondone.
Delia Derbyshire joined the BBC in 1960, originally working on a classical music review show. Her scientific approach to music presented itself immediately: she was able to look at the grooves in the vinyl records and determine exactly when a certain instrument was playing.
However, she came into her own at the Radiophonic Workshop, an in-house sound effects studio that had been established at the BBC. Here, she famously recorded the theme tune to Doctor Who:
To begin with Delia thought she had found her own private paradise where she could combine her interests in the theory and perception of sound; modes and tunings, and the communication of moods using purely electronic sources. Within a matter of months she had created her recording of Ron Grainer's Doctor Who theme, one of the most famous and instantly recognisable TV themes ever. On first hearing it Grainer was tickled pink: "Did I really write this?" he asked. "Most of it," replied Derbyshire.
Grainer fought for her to receive a composer's credit, but the BBC's policy was for Radiophonic Workshop members to remain anonymous. Broadcast in November, 1963, it remains one of the most hauntingly original theme tunes ever recorded:
Her later work is less well known, but is stunning: it predated EDM by around 30-40 years, but would not be out of place on a modern record label. (Her lost tapes are astonishing.)
Sadly, she didn't receive the recognition she deserved in her lifetime.
Download Known 0.9 Derbyshire
You can get Known 0.9 in .zip and .tgz formats. Our source code is always available on GitHub.
Alternatively, you can host your Known site with us.
7 min read
Known has become the easiest way to create an online community to support your class or group. We've built an easy-to-use platform that lets people publish in a group with a variety of media, from blog posts and photographs to files and points on a map. Each post can be private or public; every Known site as a whole can be private or public. And it all works on any device, from the biggest, strongest desktop to the most entry-level smartphone, as long as it comes with a web browser.
Institutions like Harvard and MIT use it to run classes; so do groups teaching web skills in rural India, activists promoting racial justice, writers who need to control their identities, and open source hackers.
Here's how we got here, and here's where we're going.
Finding a fit in higher education
We arrived at Matter knowing we wanted to give people more ownership over their conversations and content online. As well as investing in our team and creating a structured environment for us to grow our company, they gave us a grounding in design thinking which helped us change the way we think about technology businesses.
It was through this process, and hundreds of hours of conversations with teachers and students, that we discovered a deep need in education for social platforms. 98% of higher educational institutions use something called a Learning Management System - platforms like Blackboard and Moodle - but very few report that they are satisfied with the experience. These platforms focus on administration, rather than learning. While they are often used for classroom teaching, they fall comically short of the kinds of social experiences students are used to.
Enter Known. Our platform runs as a stand-alone community site, but it can also integrate with a school's LMS to add those much-needed social features. We offer single sign on to campuses, and unlike many social platforms, let you publish any kind of file you need to. All our plans come with unlimited storage and bandwidth, so you don't need to worry about capacity. We sell SaaS subscriptions, and enterprise licenses for organizations that want to run Known on their own infrastructure.
We also understand that conversations don't just happen in tiny sites on the web. Known sites can push their content across social networks: audio, for example, can be immediately copied to a SoundCloud account. Using brid.gy, we can pull replies and likes from those social networks back to the community, so everything is always stored in one place.
Social infrastructure for campuses
The possibilities are endless. Any campus can run as many Known communities as they need to. We also know that discovering all the content being created on a campus is key, so we've started to provide social hubs and search engines for all of it. On-campus users can search for content that only they can see; visitors to a campus can search for and discover content that has been made public. The result is an easy-to-use gateway to everything happening at a campus. It's never been done before.
We know that in education, one size rarely fits all. So we offer design sprints, where we'll arrive on campus and run design thinking sessions with students, faculty and staff. These allow us to tailor the product to meet the needs of a particular institution, so it complements their activities, their design, and their culture. (These sprints turn out to be useful whether you end up using Known or not.)
Because that's the other thing about Known: it's open source and extremely customizable.
An open source core
In VentureBeat, Lightspeed's John Vrionis writes:
The OSS companies that will be pillars of IT in the future are the companies that leverage a successful OSS project for sales, marketing, and engineering prioritization but have a product and business strategy that includes some proprietary enhancements. They’ve figured out that customers are more than happy to pay for an enterprise-grade version of the complete product, which may have security, management, or integration enhancements and come with support. And they also understand that keeping this type of functionality proprietary won’t alienate the community supporting the project the way something such as a performance enhancement would.
This is our strategy. Our core platform is available on GitHub: you can get it right now. We offer a fully-managed service, with unlimited storage and bandwidth, so you don't need to worry about server maintenance or capacity. But we also offer premium features like LTI integrations, file uploads, and searchable user directories.
We love our open source community. Thousands of people use Known to publish on their own site as an indieweb blog, and the activity helps us build a better platform for everyone. Every single page on every Known site has a little heart icon. Click it, and you're prompted to send us feedback. We read every single message personally, and it allows people who aren't developers or designers to contribute to the community and help us develop the product.
John goes on to say:
OSS businesses turn the customer discovery process completely upside down. Open source software is put into the wild, and the company immediately receives signals from those who are interested. Entrepreneurs get the benefit of real data and usage to help them decide where to focus engineering and sales-and-marketing resources. This is tremendously helpful and important. Data, not guessing, drives prioritization of the limited resources at a company’s disposal.
The combination of an open source development model and a design thinking product process means that we can rapidly prototype new ideas, and get strong signals from real people about the desirability of our platform.
It's obvious that a flexible community platform that runs on any device has applications beyond education. With LDAP / Active Directory integration, you can run it alongside your intranet to support a project or a company. Because you can make a community private, we've even seen families use it to share photos of their children that they wouldn't feel comfortable publishing on Facebook.
Mozilla's CEO Chris Beard said today that he thought of revenue as "a means to do better for the world". We agree: it is important to be a growing, valuable company, but in service to being able to provide a platform that can support any class and give anyone in the world a voice in a space they control. The total market for Known in education is measured in billions of dollars, but our potential goes beyond that.
We're living in a world where everyone can be connected, but only a handful of companies control those conversations. Censorship and surveillance are growing threats. By creating an open, easy-to-use platform that works on every device, we can help everyone own their own conversations. Not only can top-tier universities and companies benefit, but we can help disadvantaged communities, too. From non-profits sharing resources in developing nations to vulnerable groups who need to protect their identities right here in America, we believe we can make a difference.
Our role as technologists is to build a better future where everyone is represented. That's the promise of the web, and it's something core to our mission and beliefs. We're building what I call respectful software, and by showing it can be successful, we will encourage other vendors to follow.
Today, it's the best way to build an online community. But Known has an even brighter future ahead of it. We're excited to bring it to you.
And you can always email me at firstname.lastname@example.org. I'd love to talk to you.
This post was originally published on werd.io.
5 min read
As a company, we have a mission. We've read lots of advice since we started about how you should show, not tell, your reason for being. That makes sense to us, but here it is:
Known empowers every group and individual to communicate from their own space on the Internet.
It's a pretty simple idea: the Internet should be a level playing field for everybody, whether you're a student in a developing nation, a lone hobbyist, or giant tech company. The Internet works best when everyone can communicate with everyone else, without censorship or uneven distribution. It's an ideal we share with other open organizations like Mozilla.
One of the things that makes this work is standardization. Everything on the Internet talks the same underlying languages. It's worked pretty well for the low-level networking protocols that move data; it's worked well for applications like email; and it's worked well for the web.
The web in particular has become the most powerful communications medium human civilization has ever known. That's a pretty big statement, but consider the cultural impact of blogging and social media on society in a relatively short space of time. Facebook - undeniably part of the web - has, by itself, at least 1.44 billion people who use it regularly to talk to their friends, share photographs and learn about the world.
The web grew organically, like the Internet before it. Like any technology, it's a little older now, and it's missing a few things. There's no agreed-upon concept of identity on the web, and no way to represent actions like "sharing" and "liking". We are also in a multi-device world, rather than one where we access the web solely from a computer screen. Understandably, work is underway to upgrade and improve the standards we rely upon. Just as we need HTML to have an agreed-upon way to display information on the web, we now need a way to deal with these new uses of it.
Standards without grassroots adoption are just bureaucracy. It's crucial that any new "standard" is broadly embraced without coercion.
These standards can't be dictated by large corporations alone (although they're an important part of the web ecosystem). If we want the web to continue to be the platform for innovation it has been to date, it must serve the interests of individuals: both individual developers, and people who rely on it to live and work.
In the latest version of Known, we shipped experimental support for Accelerated Mobile Pages. This is an answer to something called Facebook Instant Pages, which caches website content inside a mobile app so it can be displayed immediately. While Instant Pages content must be negotiated with Facebook, anyone can publish AMP content. So far, so good.
We've shipped support for AMP because we see potential here, and recognize that something should be done to improve the experience of loading independently-published content on the web. But attempting to bake certain businesses into a web standard is a malformed idea that is doomed to fail. If this is not corrected in future versions of the specification, we will withdraw support.
Elsewhere, we see other web standards efforts attempt to bake in certain ideologies or approaches. I think it's important to understand that the web succeeded because:
Here's what I think that means in practice:
Open: Any new web standard must be created as part of an open process. Imagine if Marc Andreessen hadn't been free to propose the img tag, for example. It also can't be created behind closed doors, or solely as part of organizations that require an entrance fee. The conversations that shape the standards have to be open, too, which means being welcoming to newcomers and understanding of different personal contexts.
Easy: Any new web standard must be easy enough to understand and implement that a developer can get something up and running in an afternoon. HTML, HTTP and RSS all adhere to these principles. So do the indieweb protocols, which is why we support them and think they are likely to succeed.
Agnostic: Any new web standard should not give preference to any company or organization.
We believe in the web, and the Internet as a whole, as an incredibly powerful platform for innovation, business, communication and personal expression. To do that means standing up for openness and accessibility.
1 min read
We just released Known 0.8.5, which you can download from our website.
This version contains expanded support for the micropub open standard, so you can use open tools like Quill and Woodwind to post to your Known site. It also contains experimental support for Accelerated Mobile Pages. We have more to say about both, and open standards on the web in general, at a later time.
There's also a new command line tool, with a simple plugin interface, so server administrators can script certain tasks to run automatically.
Here's the full list of changes:
If you prefer, of course, you can get a fully-featured Known site on our fully-managed service.