Part of the Process

This week has been about kicking off projects at work and a major release for my side project. Because of this my reading has probably gravitated towards thoughts of design, focus and leadership around both.  Voice-Enabled Design is different enough to "point and click" that I think it will lead to some change of the profile of Product People. Interesting theory here that Drama Teachers will be the ideal people to lead the charge here.  Drama teachers may be one specialism IT could do more of. Critical thinkers is another. For example  “I think it will make for a perfect alarm clock”  Trusted Reviews - Amazon Echo Spot Here it looks like part of the problem with technology is the largely uncritical approach of what could go wrong, in building and selling, no mention of privacy concerns apart from throw away comment about a "mute" feature. Maybe they fell foul of the issue in this great quote from  Davide Vitiello in his  Focus vs Product Team St...

This post is the story of a personal journey. It starts with a legacy product. Both powerful and flexible having grown to meet needs over time. But it is my view on steps to improve the process in my context - so your mileage may vary. Phase 1: Transactional DB as source Started with looking at the transactional data. Some things were obvious, one option in the UI is recorded as true/false in the DB. Some were more complicated and required more investigation. To back this up we conducted a user survey. Followed up by a workshop to find the most important user journey to concentrate on. This highlighted three related journeys. The key characteristic of activity in this phase was mining different structures of data. The format of the data coming from custom reports. Getting to the questions to ask was guided by a user survey to almost the whole user base, a smaller workshop looking at the "job to be done" for the platform. Other than that the skills needed where accessib...

Photo by Sebastiaan ter Burg So having a good roadmap with themes it is now important to get the work delivered somehow. Unless the developers have done something similar enough before. You need some way of discovering how to chunk up the work. What you call this doesn't really matter, but I have used the agile term "spike".  According to a comment in the Agile dictionary , this is a rock climbing term. A spike is driven into the rock face to help support the climbers. Although it does not get us closer to the top it allows us to go faster and have a safer climb. Likewise, a development spike doesn't produce the feature faster, but it provides a foundation to move forwards. In a project kick-off meeting, I remarked about how successful the spike had been. A developer there joked that I should write a blog about it, so here it is... "challenge accepted". I have been reflecting on what I feel made the spike successful. This particular...

This post has had a long gestation period, starting after I attended the BCS PROMS-G Spring Summer School on Risk in 2013! I've been thinking a lot recently about process and why we do it and what we hope to achieve. In my experience there are a large group of people who cringe when they even hear the word "process", seeing it as a command and control mechanism. But I believe that for every necessary process there is a positive by product that we should be focussing on, and working with, for improvement. To illustrate this I will discuss a design review process. Say an organisation has issues with the introduction and evaluation of new technologies and techniques. So the re-action is to introduce a formal design review process, with feedback from various stakeholders and sign-off before the change gets the go ahead.  The tale of the 6 blind men and the elephant where different perspective and views on an issue, we need to see the bigger picture and get a common p...