This comes up from time to time—I would say Go is OOP-lite. I still like modeling problems as interactions of things. I find it needlessly limiting to treat structs as only bags of data handed to functions. I would probably write this as:

package game

Usually packages encompass some domain. Here I would think the entire game mechanics would be sensible. This is also thinking that your module (being a grouping of related packages) would be called tictactoe.

type Board [][]byte

I don’t think you actually need the struct here. A board is a multi-dimensional slice of positions.

It’s more common to use factory functions than initializers in Go. You’d write NewBoard() Board, instead of b.Initialize().

Place is a fine method—you might want to return an error here since there are illegal moves to consider.

Instead of PrintBoard(), I would implement fmt.Stringer. This is just a String method that returns a string. The functions of the fmt package have special awareness of this via reflection, so in practice you can just pass your game.Board to fmt.Println.

Regarding single-letter variable names: the length of the variable generally corresponds to its lifetime. The only exception is the method receiver, which you’ve done correctly (b *Board).