5 ms·
Other tools primarily track tasks or issues. In Kitemaker, you will track work items representing features, fixes, and experiments you plan to ship to your user
by stinos 4y ago
Other tools primarily track tasks or issues. In Kitemaker, you will track work items representing features, fixes, and experiments you plan to ship to your users.
Either this doesn't express the intent properly, or it summarizes as 'you call it issues, we call it work items' i.e. not really a difference. From the screenshots it also doesn't really look too different from other software I'm using (work items, like in other issue trackers, have labels and priorities and members and so on, can be put in a roadmap, etc.). My takeaway would be: if you want me to sign up to try this, you should highlight differences with say Jira/Gitxxx premium/...
- SigKill9 4y agoThanks for good feedback! Noted! It's always hard to convey how you are different in a few words on a webpage. Teams that do try Kitemaker find us quite different, but getting the message across on a page that people (mostly) skim is not super easy.
- deleted 4y ago[deleted]
- magicalhippo 4y agoI was feeling dense because I couldn't figure out what was so different. Some short, concrete examples would go a long way I think.
- kevsim 4y agoAppreciate the feedback! Nailing landing page copy is tough. So you'd like to see something along the lines of "in Jira you'd do it like XYZ, in Kitemaker it'd look like ABC"?
- twohaibei 4y agoYou could even go a step further and play the SEO game by creating landing pages for all the comparisons. Ie. vs Trello, vs Jira, vs Github Issues. Zapier did it (and automated) with success.
- kevsim 4y agoThanks for the tip! Zapier's SEO prowess is awe inspiring.
- HelloNurse 4y agoFar from a time-wasting "SEO game", comparison pages would be highly informative content (an unavoidably detailed and accurate product description) and a very good advertisement (showing and not merely telling how and why whatever one's currently using or considering is inferior).
- magicalhippo 4y agoIn the article you say We should be focusing on what we plan to deliver to our users, regardless of the size. This is at the center of “outcome” before “output” What I'm struggling with is seeing exactly how tracking a huge, "fluffy" outcome would be an improvement. For example, at my work we recently got a fairly big customer. As part of that, we will need to integrate with about 30 of their systems as well as implement a new API for them to send data to us. Reading what you've written naively, it seems to me we should have a single "Integrate customer Foo" task to track. Without further details, I struggle to figure out to what degree this would be an improvement to what we're currently doing, which is using JIRA issues for high-level stuff like "integrate with invoicing system A", with a bunch of sub-issues for the details. It could very well be we're missing out on something amazing, but without any concrete examples to compare to what we're doing, it's hard to determine. At least for me.