|
Another Friday, another update!
I worked on my current client project most of the time this week. I further learned about Craft CMS and set up all the technical requirements for the new website. The graphic designer worked on the visual appearance and after approval from the client, I will start implementing it with Craft CMS.
As I do not have much more to say about this project at the moment, I want to write a bit about a way of thinking I learned over the last couple years.
|
|
Demand Thinking
I'm a big fan of Basecamp (formerly 37signals) and their way of doing business, their products and their thinking behind it. I read all of their published books (Getting Real, Rework, Remote) and visit the blog Signal v. Noise regularly. Over time I learned many valuable lessons for myself and my professional life.
Ryan Singer is a designer and head of product strategy at Basecamp. In this role he learns about the work of their clients on a daily basis and tries to find out how their product can help them achieve their goals. He has a way of doing this kind of work which, unfortunately, is not very common in the field of software development. Often times it is about adding just another feature, having everything that the competition has or even better, more than the competition has.
Ryan uses the analogy of a fishing net; software companies try to create as big a fishing net as possible, hoping to catch one or two new clients in an already over-harvested ocean. This inevitably leads to cluttered software products with barely usable user interfaces, slow responsiveness, big maintenance efforts and little possibilities to change anything.
Ryan advises one should concentrate more on the demand side of things – what does my client try to accomplish – and not so much on the supply of the product. That's what it is all about in Demand Thinking. In short video episodes he speaks about different techniques and real life examples, together with Chris Spiek. In episode 2, Ryan explains the CSR-method which goes like this:
A specific process of the client is divided into three stages:
- Circumstance: Where was the client, when did he try to accomplish what, etc.
- Solution: How did he try to do his work, which utility/feature of our existing product did he use, etc.
- Result: what was the outcome, what did not work, what was difficult etc.
The achieved result was most certainly not what the client expected, since it lead him to write a feature request.
The circumstance won't change as the client still needs to do the same task at the same time. But we can rewrite the result to the desired outcome, since this is what the client expects.
Now we can come up with a new solution which brings us from the given circumstance to the desired result. The solution found this way most likely won't be as big or take as long to implement as the originally proposed solution from the client.
For some time already, it was clear to me that I need to intensively research the processes and demands of the users to develop the best software product possible. Unfortunately, most software companies do not consider this enough in their day to day work, as they are focused too much on achieving feature parity with the competition, blindly implementing all the proposed solutions from clients or finishing their own fishing net.
I will work hard to always implement this way of thinking into my own project Wellfunded but also into my clients projects to achieve the best solution possible for the user.
Hopefully, you find these methods as valuable as I do. If you want to learn more about it, I suggest watching the video episodes of Demand Thinking and read more about Jobs-to-be-done.
I'm available from mid-November onwards to provide my knowledge and these methods to new client projects. If you, or someone you know, need a helping hand, please get in contact with me!
|
|
Thanks for reading.
And now off to the weekend!
Beni
|
|
|
|
|
