Today I handed in my first #ProductProposal 🥳

And it was quite fun to write it.
Since pitching products is not my day-to-day business I spent some time to research how to write such a proposal. My first search results were aimed at “elevator pitches” or “startup pitches”. So I had to dig deeper ..

Anyway: due to confidentiality I can’t show-case anything here. I can only share this: I drew some #mockups with draw.io, put in the technical features and spent the majority of the time on writing a teaser. Something which will catch the audience immediately and makes them think: wow, we really have to sponsor this project!

Oh, why do I say “we”? #datamodul opened an innovation contest to source the ideas of their employees. Quite a clever idea. And a team can achieve so much more than a collection of individuals.

So .. even if that proposal is a dud, I learned some things, especially about writing a proper introduction. My first iteration was quite technical 😅

# Lessons learned:
* How to do a proper pitch, reduce technical details, appeal to a #vision, create a pitch deck with slides
* But also: go fast, break things. Too much time was spent on refinement and polishing. I had set myself an arbitrary date six weeks ago and in retrospective I had already 80% of the material at that time. I’ll be better next time: #time-boxing upfront.

Is this a bug?

Let’s assume the following situation: in the past a feature was implemented, a full DoD (code review, manual test, stakeholder approval, ..) was done and the ticket successfully closed.
Suddenly someone realizes that a second feature, which is closely related to the first one, should have that behaviour as well. The circle of people cavilling about the lack of functionality is identical with the people writing the requirements and doing the validation of the implementation of feature one.

So, is this a bug?
No, this is a new task!

It is devaluating the efforts of all people involved in first place, because the work was delivered like ordered. Nobody complained – until now.
Let me explain, because this sounds like nitpicking and fussing about the wording. But the inner problem is, when stakeholder and requirement engineers couldn’t capture all use-cases or had implicit, inner expectations and did not note them down before (or while) development, then you can’t suddenly name the lack of some additonal change a bug.
Or you can. If you want to piss of your developers :>

Another aspect: at the end of sprints or releases reviews are done. And at this very moment only numbers matter. You won’t dive into the details of each tickets – so only the binning of the types of solved issues matter. And mislabelling the aforementioned tasks as bugs can make a good-team result appear like a “barely made it over the finishing line”.