A practical guide for getting ideas to production – Part 3

Part 1 of this series was about how to get an idea worked out into artefacts. In part 2 I illustrated this flow a bit more with examples and created the artefacts. This part will be about translating these artefacts into user stories and acceptance criteria. The result of our activities in part 1 and Read more about A practical guide for getting ideas to production – Part 3[…]

A practical guide for getting ideas to production – Part 2

Part 1 of this series was about how to get an idea worked out into artefacts. In this post I will illustrate this flow a bit more with examples. In that post I stated that ‘Writing user stories is literally the least of your concerns’ because if you have a structured flow in which you Read more about A practical guide for getting ideas to production – Part 2[…]

A practical guide for getting ideas to production – Part 1

In previous blog posts I explained something that I would call a typical product flow. In this flow you start with strategic goals and transform them in a controlled way to working software that your users can use: In this blog series I elaborate more on this flow in a practical way. I will share Read more about A practical guide for getting ideas to production – Part 1[…]

Better software sooner

Most methods, frameworks and technologies promise, some more implicitly than others, that they are the way to create products faster. Or better. Or both. Well, there is good and there is bad news. The bad news is that there is no magic all-containing one-size-fits-all solution that you can buy which results in better software faster. Read more about Better software sooner[…]

There is no such thing as “the business”

In regards to agile stakeholder management there are two important patterns I often see: – Product Owners in general are really busy managing the “the business” or “the stakeholders” but no inventorisation and classification of these groups is being done. – While the business or stakeholders are not mapped, we pretend to exactly know what Read more about There is no such thing as “the business”[…]

Impact mapping and continuous validation

There is always a reason for making software. Let’s rephrase that: there should always be a reason, at least from a business perspective. How else could our products have any impact? Whether we want to make an app that that seamlessly connects riders to drivers or build a community where you can hire and rent apartments while Read more about Impact mapping and continuous validation[…]