So: I am a Product Designer, and I am very happy having that role in thiscompany.

I am not strictly a UX Designer, as I do not do research, personas, card sorting or what else you might see in a workshop title at a UX conference.

Well, I also do that, given how our users’ experience is always at the heart of what I do, but most of the methodology mentioned above is the work of our Product Manager. He does the user research with real users, as the early phase Opbeat finds itself in leaves out constructing elaborate personas just yet. We might as well just talk to real users and show them what we think they will like, instead of wonder about what a persona might like. (Or, well, we kinda also do that when we think up new features—otherwise it would be kinda hard to go anywhere with the product. It is just that we have not constructed a set persona that we reference. We look at ideas we have had before, new ways to do what we already see people do in some way, and what we believe people could find useful when they use Opbeat.)

I do not do visual design. Well, I also do that, since I make something people look at with their eyes. But it is more a work of piecing together screenshots of Opbeat running in the browser with added CSS hacks in the Inspector, sprinkled with slices of images, and a dash of vector graphics created in Sketch, and then showing it to users, watching their reaction and listening to their feedback. Only then is it either polished in Photoshop, or (preferably, but not always) implemented right away.

“What about wireframes and information architecture?” you might think. Wireframes and information architecture are embedded in the visuals I create and we show to users. I do not create a full hierarchy of how all pages link to each other, but when we put something on the screen you can click on, we need to know where it leads. That is the beauty of working on a product that already has a hierarchy of pages; you know when you replace them, when you add to them, and where your new piece fits in.

It might sound a little haphazard to just (if you see it from a negative point of view, which I do not) wing it like this, but we are at an early stage with our product, trying to put a lot of things in front of users and get as much feedback as possible. At this point, we do not have time to sit around and sweat over the small details of everything; but that does not mean we do not think about what we put out there—quite the contrary. It is exactlybecause we put so much in front of users at an early stage that we are able to only improve the product with the features and polish we—and our users—find absolutely essential.

This process is the truest form of agile product development I have ever seen. Not because we have scrum masters and estimations, but because we are freakin’ fast.

It also lends itself well to my working style, having been at an agency for two years where some days at 9 o’clock, I would not have a clue about what I would work on that day. It prepares you for taking on tasks that might seem huge, and weirdly complicated, but at the end of the day are distilled to an essence of purpose.

Working like that builds confidence in what you produce, is what I am trying to say, and that is a very useful skill to feel you possess, when you are building a product you do not quite know the scope and possible impact of yet.

I know what I think the impact of the product is, and that is what we are working on proving every day.